Hi Olivier, On 2019-02-10 00:13, Olivier Bonaventure wrote: > Reviewer: Olivier Bonaventure > Review result: Ready with Nits > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@xxxxxxxx if you reply to or forward this review. > > The document proposes lower than best effort service and discusses its > implementation using Diffserv techniques. It is generally in good shape, but > there are two parts which could be clarified from a transport viewpoint. > > First, Section 3 mentions : "Since > LE traffic could be starved completely for a longer period of time, > transport protocols or applications (and their related congestion > control mechanisms) SHOULD be able to detect and react to such a > starvation situation. " > > This is an important point for such a service. Applications and/or transport > protocols that are intended to be used with this service should be capable of > supporting long losses of connectivity that may cause connections to fail. The > document should strongly recommend to only use this service with > applications/protocols that are capable of resuming an aborted data transfert. Isn't that what the SHOULD already says? There's no implication that one would use TCP. I would expect a pragmatic UDP-based mechanism. But I don't think this draft should cover that - its role is to define the code point and the per-hop behaviour, not the end to end protocol. > A regular TCP connection is usually not capable of doing this and thus using > the service correctly requires more than simply tagging the packets sent by a > given TCP connection with the chose DSCP. > > Later, the document states " While it is desirable to achieve a quick > resumption of the transfer > as soon as resources become available again, it may be difficult to > achieve this in practice. " > > I'm not personally convinced that a quick resumption of the transfer is the > best approach to deal with periods where no LE packet is forwarded by the > network. If a connection using LE fails, it does not seem to be appropriate to > try to resume it immediately. It is likely that an approach like exponential > backoff could make sense to avoid trying to restart such connections too early. Yes and no. Suppose that the LE class is starved on a particular path except between 2 a.m. and 4 a.m. every morning. A naive exponential backoff would start at 4 a.m. on Monday and by 2 a.m. on Tuesday it could have reached a timeout of more than 2 hours. To make prompt use of the bandwidth at 2 a.m., it would instead need to be retrying every minute or two. Again - we shouldn't say too much about this in the PHB definition. > Second, there is a small discussion of ECN in section 4: " Since congestion > control is also useful within the LE traffic class, > Explicit Congestion Notification [RFC3168] SHOULD be used for LE > packets, too." > > Does this imply that LE packets SHOULD also be ECT capable packets, i.e. when a > transport protocol is used to provide LE service, it should also support ECN or > is this requirement weaker ? Same comment - a good question, maybe a good M.Sc. topic, but not part of the PHB definition. > Finally, Section 9 discusses the Multicast considerations. It mentions the > utilisation of forward error correction schemes. One risk with FEC combined > with LE is that FEC increases the amount of data that needs to be transferred > and thus consumes ressources in non-congested parts of the network for packets > that will be discarded downstream during periods of congestion. If there are > simulation or measurement results that demonstrate that combining FEC and LE > provides good results, it would be interesting to cite those results. I agree, although LE only makes an existing problem worse. There does seem to be some literature on FEC+diffserv+multicast, e.g. https://doi.org/10.1109/ICECS.2003.1301723 Regards Brian
