Hi Olivier, Am 09.02.19 um 12:13 schrieb Olivier Bonaventure: > Reviewer: Olivier Bonaventure > Review result: Ready with Nits thanks for the review. See comments inline. > 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. > 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. That is correct. That's why it's stated in the draft. So one can use TCP and hope that it works well enough with the available residual bandwidth, but the application should be prepared to react on a connection timeout and initiate a new TCP connection with an application level session resumption. In other cases one can probably use a transport protocol that is specifically designed to deal with this kind of starvation periods. However, that is the worst case and I would expect that there is always some residual bandwidth for LE available. I think that it is application dependent, whether long starvation is acceptable or a connection timeout should indicate a failure (taking Christian Huitema's comments into account). > 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. You are right. I had something like an exponential backoff in mind, but probably with some kind of upper bound (retry every minute or two). This statement came in by a comment from Spencer who referred to the trigtran experience. I can add a bit more text on this. But as Brian Carpenter already mentioned: this is a PHB specification and transport protocol issues are related but would be a different focus. > 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 ? Again, since this is a PHB specification, the focus is on forwarding. For ECN you need both: the ECN capable transport protocol and the ECN marking in the queue. So the recommendation is to use an ECN capable transport (that would use ECT) for LE and to have ECN capable marking for the LE queue. The recommendation was targeted a bit at the latter: if the node is able to set the CE bit, then it only depends on the transport to use ECN (which is also recommended). I'm not sure that this should be stated more explicitly. > 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 think the idea was to use LE for the redundancy data only as the last sentence points out: "The previously mentioned redundancy data traffic could nicely use the varying available residual bandwidth being utilized the by LE PHB, but only if the previously specific requirements in the internal implementation of the network devices are considered. So the normal data stream uses BE, while the FEC data uses LE. The multicast considerations were suggested by Toerless Eckert. Maybe he can provide some pointers if there are some. best regards Roland
