Skip to main content

Last Call Review of draft-ietf-tsvwg-le-phb-08
review-ietf-tsvwg-le-phb-08-tsvart-lc-bonaventure-2019-02-09-00

Request Review of draft-ietf-tsvwg-le-phb
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-02-12
Requested 2019-01-29
Authors Roland Bless
I-D last updated 2019-02-09
Completed reviews Tsvart Last Call review of -08 by Olivier Bonaventure (diff)
Secdir Last Call review of -08 by Kyle Rose (diff)
Genart Last Call review of -08 by Brian E. Carpenter (diff)
Assignment Reviewer Olivier Bonaventure
State Completed
Request Last Call review on draft-ietf-tsvwg-le-phb by Transport Area Review Team Assigned
Reviewed revision 08 (document currently at 10)
Result Ready w/nits
Completed 2019-02-09
review-ietf-tsvwg-le-phb-08-tsvart-lc-bonaventure-2019-02-09-00
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@ietf.org 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.