Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

[Toerless Eckert <[e-mail]>]

On Thu, Apr 12, 2018 at 01:54:14PM +1200, Brian E Carpenter wrote:
> 
> 
> On 12/04/2018 13:25, Toerless Eckert wrote:
> > On Tue, Apr 10, 2018 at 02:59:17PM +0200, Bless, Roland (TM) wrote:
> ...
>  
> >>> I) LE CC must ensure that if operating across a congested hop that
> >>> is treating LE as BE, LE CC MUST NOT give LE traffic more bandwidth share
> >>> than the competing BE traffic, and it SHOULD give it less share.
> >>
> >>> So i hope thats the uncontentuous part. Here is the interesting part:
> 
> Why is this needed when the text already says:
> 
>    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.

I) is meant as a requirement against LE CC. If formally a traffic classes
CC requirements are not part of the PHB, thats fine. If we need a second
document with a one paragraph LE CC requirement becasue we should not
specificy CC requirements and PHB together in one document that would be silly,
but IMHO then we need such a second 2 page document. Or where else would
you define the CC requirements ?

Note that the biggest issue with the above text is that it
does not help any SP that ha no idea what LE is and therefore
his routers along the path will treat it as BE. Only BE compatible
LE CC will help them and allow to safely let LE traffic onto the Internet.

Beside that:
I havent really commented on that text segment in before, but i am a
bit worried that it could be interpreted as if LE could perfectly
be "supported" in a single queue with BE by just assigning it a different
drop profile, and from past experience trying to figure out the impact
of different drop profiles during contention, thats a black magic and
does not lead to operationally predictable outcomes.  But of course i
have been burned with this, so i am paranoid.

In fact i think the text is correct and would NOT permit BE and LE to
be in a single queue, but i would certainly prefer more directive text - 
aka: something saying LE should ideally use a separate lower priority
queue from any other traffic class queue, but that a weighted
fair share queue with a share of 0 is fine too. This can be informational,
but IMHO we should strive to make adoption easy and not a guesswork.

> BE and LE PHBs should talk about queueing and dropping behaviour, not about
> capacity share, in any case.
>
> It's clear that on a congested link, LE
> is sacrificed first - peak hour LE throughput might be precisely zero,
> which is not acceptable for BE.

Right. which is another point i raised in another mail: If we
really make LE go to 0 for long periods, we really should have
informational text about hybrid BE/LE use, or we won't get
any adoption. Otherwise apps using only LE will be written,
and then they won't work well enough, and especially in enterprises,
network opeators might give LE some traffic share > 0, and then that
share number becomes yet another magic parameter you need to plan
and update based on your LE traffic profiles.

Cheers
    Toerless
> 
>      Brian

-- 
---
[e-mail]