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". 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. 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) ? 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. 2., first paragraph, "to process" Is a PHB processed ? "implement" may be better. 3.1, page 5, last paragraph on page, "semantics allows" Typo. 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. 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. 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." 3.2, 2nd paragraph, "by setting". Sounds a bit like an implementation again. Suggest "providing". 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 ? 3.2, list, page 7, Application information. Idem. 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. 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 3.2, page 6, last paragraph of section, "[...] there are restrictions [...]" Maybe they should be mentioned more explicitly. 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 ? 3.3, 2nd paragraph, and also section 3.4. Again, "excess" is a difficult concept if there are multiple levels of conformance. 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. 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. 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. 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. 3.5, disclaimer. Good point. Throughput indeed seems to be unnecessary. 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.) 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 ? 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. 4.3, flow specification, "AF-PBH" Typo. 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. 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. 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.