Koch Berthold wrote:
>
> Dear all,
>
> on behalf of Werner Almesberger (EPFL) I'm sending his comments on the
> TEQUILA draft.
>
> Best Regards
>
> Bert
Bert, Werner,
thanks for the comments. reaction included as [Y]
Cadenus comments on draft-tequila-diffserv-sls-00.txt
-----------------------------------------------------
General, orthography:
draft-ietf-diffserv-new-terms-03.txt uses "an SLS", never "a SLS".
draft-tequila-diffserv-sls-00.txt has eight "a SLS" and only one
"an SLS".
[Y: watch the next version ;-)
1.2, 1st paragraph, "[...] outline [...] for [...] format [...]"
"format" may be misleading here. It's rather the set of parameters an
SLS contains.
Also, although the definition of a formal language is a non-goal, I
wonder if it wouldn't actually help to do so. Reason: all over section
3., some quite formal language pops up anyway, so perhaps it would
help to do so more consistently.
[Y: indeed, the original draft was more an introduction to the theme.]
1.2, paragraphs 3 and 4
Is it really necessary to justify the definition of a common language
by a set of rater specific examples ? It seems that something as
simple as
"A commonly agreed-upon set of SLS parameters and semantics is
necessary for describing the service at any point requiring an
explicit understanding of the latter."
could serve the same purpose (even if it may sound rather generic) ?
[Y: it is just an introduction, and gives a number of situations in
which a standardized approach seems highly valid.]
1.2, page 4, paragraph 4, "(template)"
Is this really a template ? Or is rather a collection of
1.2, page 4, paragraph 4, "data types"
"Data types" suggests a strong formality (e.g. a programming
language).
Maybe "units" would be more better.
[Y: protocol independent data types then, in the end it should be
formal, this was not the objective of this particular draft]
2., first paragraph, "to process"
Is a PHB processed ? "implement" may be better.
[Y: correct.]
3.1, page 5, last paragraph on page, "semantics allows"
Typo.
[Y:ok]
3.1, page 6, list.
Why is (N,N) excluded ? What if I have two sites X and Y, each with
a primary access link, and a backup link, and I want to describe
the network service between the two sites ? Excluding (N,N) seems to
require at least a justification.
[Y: well, it is ok to indicate it, however, the semantics should then
also be mentioned. does the flow id and traffic enveloppe that is
described apply to any of the ingress points ? if so, than the service
that is described can be decomposed in n* (1,N), and would be a short
notation for this. we'll mention it in the next release.]
3.1, general.
Typical SLAs in use today include geographic references like "no more
than X ms RTT to any of our routers in Europe". Example:
http://www.uk.uu.net/customerservices/sla/tandcs/
Such specifications are probably too difficult to express in a general
formal way, so the current approach of ignoring them seems
appropriate.
Nevertheless, it may be good to mention them, simply due to their
current practical relevance.
[Y: agreed, this would be a newly defined scope then... agreed ?]
3.1, page 5, disclaimer.
Isn't this sufficiently vague that one could simply say
"[...] IP address, but it may also be any other mutually agreed upon
identifier which uniquely identifies a boundary link."
[Y: indeed.]
3.2, 2nd paragraph, "by setting".
Sounds a bit like an implementation again. Suggest "providing".
[Y: agreed again.]
3.2, list, DSCP.
Why is it only a single DSCP ? Also, is there only a single Flow ID
per SLS, or can there be many ?
[Y: theoretically it can indeed be multiple DSCPs. a little bit in
contrast with the reply to marcus, i would assume the Flow ID to express
these packets that determine to which stream the contract applies.
Therefore, there should be one Flow ID, however, that can be the
aggregation of many microflows, aggregated along the parameters in the
flow ID.]
3.2, list, page 7, Application information.
Idem.
[Y: ok.]
3.2, list, page 6, Source information.
This highlights some problems with the formality chosen: usually,
"X" and "set of X" are distinguished. But here (and also for the
destination), "set of source prefixed" only appears as a set.
[Y: maybe inconsistency, we'll correct]
3.2, page 6, BA/MF distinction.
In order to allow maximum flexibility, wouldn't it be better to
allow a combination of DSCP and the other elements ? That way,
one would obtain:
if only DSCP -> BA
if no DSCP -> MF
anything else -> probably also MF
instead of
if BA -> only DSCP (or nothing at all ?)
if MF -> no DSCP
[Y: not particularly, MF could potentially also include DSCP as far as i
know. Do you exclude DSCP for MF ?]
3.2, page 6, last paragraph of section, "[...] there are restrictions
[...]"
Maybe they should be mentioned more explicitly.
[Y: ok. it is just that these parameters can be conflicting, indicating
a flow that in practice will never be seen at a certain ingress link...]
3.3, page 7, 1st paragraph.
How does "in" and "out" relate to models involving multi-color
markers, e.g. AF ? Can conformance tests be combined, and if yes,
how ?
[Y: yes, conformance tests can potentially be hierarchically structured,
whatever formal language we choose, it should be capable of describing
this. therefore CIM is indeed a good candidate.]
3.3, 2nd paragraph, and also section 3.4.
Again, "excess" is a difficult concept if there are multiple levels
of conformance.
[Y: agreed.]
Suggested changes to 3.3 and 3.4:
- add concept of multiple levels of conformance, e.g. by allowing
multi-rate meters (NB: draft-ietf-diffserv-mib-04.txt is even a
little more generic, e.g. they also allow chaining of independent
meters, so even multi-rate meters should not be the only allowed
choice)
- allow specification of performance guarantees for each level of
conformance
Furthermore, the following two parameters should be added:
- ordering (currently the end of page 8) among flows selected by
(FlowID,multi-rate_meter) pairs
- any (re-)marking that may occur. This is particularly relevant
because DSCPs are visible at the FlowID, so SLS' can't be
concatenated without this information.
3.3, peak rate.
Might be better to explicitly express this as a separate token
bucket.
3.3, page 8, "Notes:" section.
Empty.
3.4, list "[...] reordering MUST be avoided when remarking [...]"
These concepts are largely orthogonal. Re-marking should only be
relevant at egress. Anything happening in the ISP network is
opaque.
[Y: how do you mean only at egress ? any transport provider is free to
remark packets at ingress. Certainly to differentiate in and out of
profile]
Note: this magical property of re-marking seems to re-appear in
4.3, Excess treatment: "Remarking MUST be indicated"
3.5, list.
Formalism problem: "- delay | optional quantile" means, according
to 3.1 "EITHER delay OR an optional quantile". Again, a more formal
formality may help. Alternatively, a comma instead of the vertical
bar is probably an improvement too.
[Y: ;-) indeed.]
3.5, general.
Also the time interval over which the performance guarantees are
given should be described. There may even be multiple sets of
performance guarantees for different time intervals.
[Y: here you hit the most difficult problem to solve... We should go
back and look for a measurement paradigm as in IPPM, or define ourselves
some time intervals parameters...]
Technically, this may be either in wall-clock time, or also in terms
of traffic events, e.g. starting with a packet edge. While the recent
EF discussion has painfully shown the importance of such subtle
distinctions, it's probably sufficient for SLS to consider only
wall-clock time, i.e. minimum intervals.
[Y: true. what would be a minimum interval ? 10 seconds ?
3.5, disclaimer.
Good point. Throughput indeed seems to be unnecessary.
[Y: you mean ffs is solved ? ;-)
3.5, "Qualitative performance guarantees"
This seems far too specific. Why only 3*3 types ? A more generic way
to express qualitative guarantees would be to make them relative, e.g.
green := FlowID == X && TokenBucket(Y) == OK
red := FlowID == X && TokenBucket(Y) != OK
Performance guarantees:
green: loss(green) <= 0.01 if observed over > 5 min &&
loss(green) <= loss(red) if observed over > 2 min with
loss(red) > 0
red: none
(Note: the "loss(red) > 0" clause is necessary. Otherwise, an
observation
starting with the loss of a green packet immediately before congestion
ends would yield loss(red) < loss(green) for arbitrary intervals. Even
then, "> 0" may not be sufficient - FFS.)
[Y: purely philosophical, as soon as you indicate <= 0.01, one has a
quantitative SLS... I would leave the relative differences as operator
specific, not to be defined in the SLS, the only thing you know is that
e.g., green has better loss properties than red...]
3.7, "downtime per year"
The interval should be left open. It is quite common to find months
there. (E.g. see UUNET example above.) Q: does reliability really
belong
into an SLS or is this rather SLA-only material ?
[Y: i would argue that it is an SLS parameter. Not that every flow
should be specified with one though...]
4.1 and 4.2, traffic conditioning.
Token bucket parameter b is unspecified. BTW, a TB without b is
useless.
So there should be a clearer notion of required parameters in section
3.
[Y: ok.]
4.3, flow specification, "AF-PBH"
Typo.
Y: Per Behaviour Hop, never heard of ? ;-)
4.4, general.
The colors are getting pretty confusing. Maybe more descriptive names,
such as "low delay" or "low loss and low delay" could be used. (Or,
alternative, a reference to some stable document describing this
Olympic (now obsolete ?) service.)
5. (and also bits of 1.2, etc.)
The discussion on signaling appears premature and probably beyond
the scope of a document specifying SLS parameters and semantics.
Since any discussion of signaling is ultimately tied to specific
signaling concepts and protocols, it seems more appropriate to
delegate this to one or more separate documents, which describe the
mapping of the abstract SLS template (if we want to call
draft-tequila-diffserv-sls-00.txt this) to the respective context.
[Y: negotiation and definition of the SLSses seem to me to be pretty
tied together, although this is certainly not obvious from this version
of hte draft, agreed. ]
Also, it seems clear that draft-tequila-diffserv-sls-00.txt is
complete and useful without a single word on signaling.
Last but not least, a signaling discussion in the context of
Diffserv may get highly controversial, considering that many concepts
considered there (e.g. bandwidth brokers) are new and unproven. This
could greatly slow down any progress on this I-D.
[Y: i don't personally like the word bandwidth brokers, since different
people think about different things when bandwidth brokers are
mentioned. It is a given that services can be offered over diffserv
capable networks, and somehow these services should be described at the
edges of the network. Today this is highly static, and uses a form of
fax-signalling. We just want to have an automated infrastructure for
this...
6.
Idem. After the removal of the protocol aspects, as suggested above,
most of the security considerations listed here disappear. There might
be others, though. FFS.
[Y: I understand your doubts. let us try in the framework to give some
good reasons why SLS negotiation should be mentioned along with the SLS
formal formats.]
[Y: Thanks a lot for the extensive comments,
cheers
Yves]
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 22:11:19 CEST