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

[Dave Taht <[e-mail]>]

I plan to add support for this to sch_cake and sqm-scripts as soon as it
is standarized, as CS1 is not good enough.

However I plan to ignore the wishful thinking that any transport
can stand long periods of total starvation and just slam it into the
existing "background" bin of those two qos systems, which is ~5%
of bandwith. I believe in nagle's dictum that "every application
has the right to one packet in the network.

I think giving LE some sort of garunteed minimum bandwidth would give it
uptake, otherwise, it will not be very successful. Hopefully a bare
minimum will end up being the case in the actual deployment.



Olivier Bonaventure <[e-mail]> writes:

> 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.
> 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.
>
> 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 ?
>
> 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.