Hi Yves and Danny
hereafter you'll find a list of comments and questions on
draft-tequila-sls-00.txt
best regards.
* 1.2 : ISP are often managing organizations' CPEs, so SLS between
customer and SP may be located in various points : on the link between CPE
and PE (as you mentioned), but also at LAN interface at the CPE, etc..
* 2 : in terminology references, diffserv new terms draft should be
mentionned.
* 3 : imho the Route attribute in QBone architecture is not only
mentionned for inter-domain routing aspects but more generally to consider
the stability of routing when considering a RAR/RAA in QPS (and when
considering diffserv provisioning in general) i.e. a service request is
fulfilled as long as the initial route is maintained. If rerouting happens a
new SLS invocation/RAR could (should?) be negociated. This side comment is
anyway out of scope of the current SLS draft.
* 3.1 : traffic envelop should be defined in this section, shouldn't
it?
* 3.2 : flow description should "open the door" to applications using
dynamic ports (what most of the new interactive applications do). One simple
step is to allow range of ports (e.g. VoIP has a fixed range of allowed udp
ports : 16384 to 32767). Note that this could raise some security concerns.
More complex application discovery could be envisioned too (ffs).
* 3.2 : re-marking packet (e.g. from ingress DSCP to interior DSCP)
can be intensive resource consuming so perhaps we should recommend to avoid
it as much as possible i.e. try to define in the SLS a DSCP value that will
most probably correspond to the DSCP (i.e. associated service class) used in
the ISP network.
* 3.3 : I don't catch the main interests for defining the traffic
envelop concept.
* 3.3 : 2nd §, 2nd sentence has no verb.
* 3.3 : multi-level conformance testing parameter : I don't catch why
this is a must. And binary-based parameter seems too a multi (2) level
parameter.
* 3.3 : imho there is possible confusion between conformance and
excess treatment : peak-rate should be considered in excess treatment. The
PIB draft http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-01.txt
for example gives p 30 to 33 a clear separation between committed data
(commited rate and commited burst) and peak data (peak rate and peak burst).
* 3.5 : optional quantiles should be considered for packet loss and
throughput, shouldn't they?
* 3.5 : PDB definition draft consider percentile values. Perhaps the
SLS draft should consider quantile and/or percentile.
* 3.5 : imho it should be problematic not to consider in and out of
profile guarantees separately for throughput guarantee.
* 3.5 : perhaps we shouldn't emphasize too much colors and metals when
considering drop precedence and delay. For example, the Alternative Best
Effort draft
ftp://ftp.ietf.org/internet-drafts/draft-hurley-alternative-best-effort-00.t
xt gives a quite funny and philosophic but very serious view of green and
blue packets (green being used for low delay treatment). Yet, I'm not sure
that gold/silver/bronze classes where originally defined for transport delay
considerations and they are perhaps used differently today by ISP. So it
seems these various uses of colors and metals won't help to clarify ISP and
customers views... A "painter and sculptor" issue?
* 3.5 : bronze/red service guarantees shouldn't be considered out of
qualitative guarantees. On going efforts for Lower than Best Effort services
(see for example the bulk handling PDB and the new QBone charter (study of
LBE)) shows the community interest on loose transport services.
* 3.6 : perhaps too many service schedules examples given here.
* 4 : general comment on the examples : even if the SLS draft only
consider SLS and not TE, we should keep in mind that we can't promote the
definition of too many SLS types if these SLS have to offered through a
diffserv network. The PDB definition draft describes complex issues on
invariance of agregations. For example, it should be very difficult to
agregate VoIP and VLL services onto the only EF PHB.
* 4.1 : VLL : token bucket depth should be considered (but it's not
trivial).
* 4.1 : VLL : the time interval given for the delay guarantee seems
much too big (but it's not trivial, cf. the EF redefined threads).
* 4.4 : the bulk traffic example given seems contradictory with the
new bulk handling PDB (e.g. receiving a LBE service).
* 4.7 : today most of the ISP give performance guarantees for best
effort traffic (generally (not so) "loose" delay (RTT) and loss average
values based on backbones measured performances).
* References : I believe the TWOBIT document has received a RFC number
(tbc).
jeanpierre.garbisu@francetelecom.fr
This archive was generated by hypermail 2b29 : Wed Nov 08 2000 - 15:38:36 CET