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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Feb 2019 13:46:12 +1300

I've just reread the whole draft wearing my GenART hat, so I'll chip in
with my IMHO (even IMNSHO) comments:

On 2018-12-22 08:26, Spencer Dawkins at IETF wrote:
> 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.

Yes, that is probably enough, but the original text didn't bother me.
If you send a packet with an LE stamp, you are telling the network
that delivery is a MAY, not a SHOULD.

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

No. I assume 8085 is cited for the case where UDP *is* used, which is the
"or" branch of the parenthesis.

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

LEDBAT is cited later. 

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

No, but this draft is not defining a transport protocol, it's just
saying how the transport protocol needs to behave. I'm not sure what's
wrong with that.

> 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,

Yes. That's a possible outcome. In fact it's the difference between LE
and BE.

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

To me "support for the LE PHB" is unambiguous - the routers handle
packets marked LE according to the PHB definition in this document.
So the requirements in this paragraph apply to all other domains that
do process the DCSP but do not implement this PHB.

I have to say that since I've been a diffserv advocate since before
RFC2474 was published, what's obvious to me may not be obvious to all
readers. So I can't personally see how to make the text clearer.

Regards
    Brian

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