Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-le-phb-06

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 21 Dec 2018 13:26:32 -0600

Hi, David,

On Fri, Nov 9, 2018 at 6:41 PM David Black <[email-masked]> wrote:

> David Black has requested publication of draft-ietf-tsvwg-le-phb-06 as
> Proposed Standard on behalf of the TSVWG working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

My apologies for taking so long on AD evaluation for this document.

I have some questions that I'd like to go over, before requesting Last Call.

Thanks,

Spencer

 I think "optional" in this text

  Some networks carry traffic for which delivery is considered
   optional; that is, packets of this type of traffic ought to consume
   network resources only when no other traffic is present.

is confusing. Is it correct to say

  Some networks carry packets that ought to consume
   network resources only when no other traffic is present.

? The following text focuses on the commitment to devote at least some
resources to BE, and not necessarily to LE, and that seems more correct.

I'm struggling on two points in the following text:

  Just like best-effort traffic, LE traffic SHOULD be congestion
   controlled (i.e., use a congestion controlled transport or implement
   an appropriate congestion control method [RFC8085]).  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
   situation and ought to resume the transfer as soon as possible.

First, [RFC8085] is "UDP Usage Guidelines", which seems odd (because I'm
not seeing an assumption in this draft that LE traffic will use UDP as its
transport - did I miss it). Perhaps a reference to [RFC2914], "Congestion
Control Principles", would be more appropriate? Although [RFC6817], Low
Extra Delay Background Transport (LEDBAT)", is still Experimental, perhaps
it could be cited as an example of the kind of congestion control behavior
that would be appropriate for LE?

Second, "resuming the transfer as soon as possible" turns out to be really
hard. The TRIGTRAN effort in
https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-00#section-4.3
was intended to allow this, but ran into enough roadblocks that the IETF
didn't charter it, and I'm unaware of a better proposal since then. If
"resuming the transfer as soon as possible" is going to be a BCP14
requirement, you probably need to explain how you'd do that. Or am I
misunderstanding this text?

I'm wondering about the use of BCP14 language in Section 4.  PHB Description

   The LE PHB is defined in relation to the default PHB (best-effort).
   A packet forwarded with the LE PHB SHOULD have lower precedence than
   packets forwarded with the default PHB, i.e., in the case of
   congestion, LE marked traffic SHOULD be dropped prior to dropping any
   default PHB traffic.  Ideally, LE packets SHOULD be forwarded only if
   no packet with any other PHB is awaiting transmission.

ISTM that this is basically saying, "if you treat LE traffic the same way
you treat BE traffic, you're not helping BE traffic". I'm especially
confused by the last SHOULD - ISTM that if you do this, you're taking a
chance on permanently starving LE traffic, so I wonder if that's one of the
reasons an implementation would not always forward traffic with any other
PHB first - in which case, spelling that out might be appropriate.

I'm not understanding the first sentence in this text:

  Operators of DS domains that cannot or do not want to support the LE
   PHB should be aware that they violate the "no harm" property of LE.
   DS domains that do not offer support for the LE PHB support SHOULD
   NOT drop packets marked with the LE DSCP.  They SHOULD map packets
   with this DSCP to the default PHB and SHOULD preserve the LE DSCP
   marking.  See also Section 8 for further discussion of forwarding LE
   traffic with the default PHB instead.

Is this talking about "support" as "forward LE-marked traffic", or as
"treat LE traffic differently than BE traffic"? Or "accept LE-marked
traffic at a DS domain edge"? Or something else?

It's a nit, but

  Several forwarding error correction coding schemes such as fountain
   codes (e.g., [RFC5053]) allow reliable data delivery even in
   environments with a potential high amount of packet loss in
   transmission.  When used for example over satellite links or other
   broadcast media, this means that receivers that loose 80% of packets
   in transmission simply need 5 times as long to receive the complete
   data than those receivers experiencing no loss (without any receiver
   feedback required).

should be s/loose/lose/.