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

["Bless, Roland (TM)" <[e-mail]>]

Hi Spencer,

Thanks for the review, I'll try to clarify and do another revision.
See inline.

Am 21.12.18 um 20:26 schrieb Spencer Dawkins at IETF:
> Hi, David,
> 
> On Fri, Nov 9, 2018 at 6:41 PM David Black <[e-mail] 
> <mailto:[e-mail]>> 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.

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

Yep, this text is a remnant of RFC 3662 (sec. 1). But I'm fine
to use the proposed shortened sentence (usually, more concise
is less confusing and thus better).

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

UDP traffic could be used for LE, too. I felt that RFC 8085 is a
bit more current advice than RFC2914, but I'm happy to include this
as well.

> "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 already referenced, but in section 8 only.

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

You are right, resumption was not meant to be a BCP 14 SHOULD.
Currently the text says:
"SHOULD be able to detect and react to such a
 situation and ought to resume the transfer as soon as possible."
what was meant is that it SHOULD be able to detect and react to
starvation - as soon as resources become available again a quick
resumption of the transfer is desirable. [your point is that this
may be hard to achieve].
Standard TCP implementations may abort the connection too early,
so an LE optimized transport may use different retry and timeout
limits in order to avoid the loss of the connection.

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

Your interpretation is correct. Will try to clarify.

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

Your are right. That needs to be more precise. What is meant
is: operators that forward LE-marked traffic as BE (because
they do not want or cannot provide a separate LE queue etc.).

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

Yep, good catch.

Regards
 Roland