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

[Spencer Dawkins at IETF <[e-mail]>]

Dear David the Shepherd,

This looks close enough for IETF Last Call to me.

I do see a couple of things that I'd question, but am happy to send them as
Last Call comments if you'd like to get this in front of the IESG before
IETF 104. Just let me know what you prefer.

I think either "other" or "otherwise" can go away in this new text:

Some networks carry packets that ought to consume network resources only
when no other traffic is demanding them otherwise


and the longer I'm looking at this text, which hasn't changed, and sorry
for not noticing it during AD Evaluation,

Ideally, LE packets SHOULD be forwarded only if no packet with any other
PHB is awaiting transmission.


the more I'm thinking that "Ideally, SHOULD" isn't great BCP 14 usage,
especially with the following text, which is new in this version.

           This means
     that in case of link resource contention LE traffic can be starved
     completely, which may not be always desired by the network operator's
     policy.  The used scheduler to implement the LE PHB may reflect this
     policy accordingly.

If it was me - and this is not my draft - I'd say

Ideally, LE packets would be forwarded only when no packet with any other
PHB is awaiting transmission.

                   ^ text changes here to here  ^

      This means
      that in case of link resource contention LE traffic can be starved
      completely, which may not be always desired by the network operator's
      policy.  The used scheduler to implement the LE PHB may reflect this
      policy accordingly.

but do the right thing, because that will make your new AD happy, if Magnus
ends up with this document after I step down ...

Spencer

On Thu, Jan 10, 2019 at 8:51 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Roland,
>
> On Thu, Jan 10, 2019 at 4:36 AM Bless, Roland (TM) <[e-mail]>
> wrote:
>
>> Hi Spencer,
>>
>> Thanks for the review, I'll try to clarify and do another revision.
>> See inline.
>>
>
> I think we're in sync enough for you to do another revision. I'll let the
> document shepherd confirm that your next revision is ready for IETF Last
> Call.
>
> And thanks for the helpful response!
>
> Spencer
>
>>
>> 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
>>
>>