Re: [Tsv-art] Tsvart last call review of draft-ietf-tsvwg-le-phb-08

[Brian E Carpenter <[e-mail]>]

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
> [e-mail] 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