Subject: [tsvwg] Suggestion for draft-ietf-tsvwg-le-phb-04

From: Bob Briscoe <[email-masked]>
Date: Tue, 6 Mar 2018 18:45:39 +0000

Roland,

I like how this draft has turned out. I particularly agree with LE 
updating CS1, not just being recommended alongside it. One suggestion in 
Section 5 
<https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-03#section-5> though:

CURRENT:

    For some applications and
    services, it is favorable if the transmission is finished earlier
    than expected.  However, in some cases it may be against the original
    intention of the LE PHB user to strictly send the traffic only if
    otherwise unused resources are available, i.e., LE traffic may
    compete with BE traffic for the same resources and thus adversely
    affect the original BE aggregate.  In some cases users want to be
    sure that their LE marked traffic actually fulfills the "no harm"
    property.  Applications that want to ensure the lower precedence
    compared to BE traffic SHOULD use additionally a corresponding Lower-
    than-Best-Effort transport protocol [RFC6297 <https://tools.ietf.org/html/rfc6297>], e.g., LEDBAT
    [RFC6817 <https://tools.ietf.org/html/rfc6817>].

SUGGESTED:

    Therefore applications MUST use additionally a corresponding Lower-
    than-Best-Effort transport protocol [RFC6297 <https://tools.ietf.org/html/rfc6297>], e.g., LEDBAT
    [RFC6817 <https://tools.ietf.org/html/rfc6817>], unless for example ... <bullet list of exceptions>.

I much prefer recommending an LBE transport instead of the original 
le-min/le-strict distinction. However, I've suggested the above because 
user-preference is only one exception, and it's not well articulated 
here anyway (IMO).

Normally a "SHOULD" needs to also explain in what cases an 
implementation will not follow the recommendation. The logic of the 
preceding sentence would imply that the exception to the SHOULD is when 
the application does not want to comply with the "no harm" principle. Or 
put another way, when the application does not care about harming BE 
traffic. I don't think that's how you intended this to be interpreted, 
given a sociopath wouldn't be using LE in the first place.

However, I can think of cases where an application would not need to use 
an LBE transport, e.g. where the app knows by configuration or measurement:
* that all bottlenecks on the network path support the LE PHB,
* or that the network path has really high capacity that is rarely used,
* or that the volume of traffic to be sent is not that great.
* or that the application could use DF, but LE would be preferable if it 
was available (which is what I think you meant)

So here I would argue for a sentence construction like "MUST use LBE... 
unless for example...", followed by some example exceptions, like my 
bullets above.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 16 Mar 2018 15:23:43 +0100

Hi Bob,

thanks for your suggestions. However, I think that a MUST is too strong
here. So I propose to leave it a SHOULD, but I will expand the text a
bit more  on the circumstances when it is ok to ignore the
recommendation and probably use your list of examples as starting point.

Basically, I argue that traffic that would normally use BE qualifies
also for being transported by LE: in case of being elevated to BE
there will be no severe consequences for other BE traffic.
This includes also traffic that is currently using UDP without
any congestion control. For LE traffic that could severely impact
other BE traffic if elevated to BE, users SHOULD use an LBE transport
in addition. Another problem is that LEDBAT has several severe problems,
so I would not recommend it as mandatory to use (that may change if
LEDBAT++ gets standardized).

Regards
 Roland

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 16 Mar 2018 17:01:25 +0000

Roland,

It is only reasonable to say that "LE traffic that will not severely 
impact other BE traffic if elevated to BE" SHOULD use an LBE transport.

It is not reasonable to say that "LE traffic that could severely impact 
other BE traffic if elevated to BE" SHOULD use an LBE transport.

A couple more responses inline...

On 16/03/18 14:23, Bless, Roland (TM) wrote:
> in addition.
[BB] The list you are going to include will consist of cases where LE 
traffic will /not/ severely affect other BE traffic.

Here you are saying that, even "where LE traffic could severely impact 
other BE traffic" using LBE is still only a "SHOULD". Surely you don't 
mean that.

> Another problem is that LEDBAT has several severe problems,
[BB] I wouldn't say "MUST use LEDBAT..." anyway. I would say "MUST use 
an LBE transport, such as LEDBAT...".

Bob

---

From: Roland Bless <[email-masked]>
Date: Thu, 22 Mar 2018 14:04:06 +0000

Hi Bob,

I'm not sure that I'm able to follow.
My proposal is to write something along the lines of
"LE users SHOULD use LBE transport, because ...
Otherwise, ...[list of implications/negative effects if LBE transport is
not used]"

This is inline with RFC 2119:
SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Regards,
 Roland

On 16.03.2018 at 17:01 Bob Briscoe wrote:
>>>     than-Best-Effort transport protocol [RFC6297
>>> <https://tools.ietf.org/html/rfc6297>], e.g., LEDBAT
>>>     than-Best-Effort transport protocol [RFC6297
>>> <https://tools.ietf.org/html/rfc6297>], e.g., LEDBAT

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 22 Mar 2018 16:26:36 +0000

Roland,

I'll say this at the mic, but the point is... the choice over whether to 
use LBE is not about whether the application /wants/ to avoid harming BE 
traffic. It needs to be about whether the traffic /is/ likely to harm BE 
traffic.

Then the question of SHOULD/MUST will need to be addressed again, but 
that's a new question.

Bob

---

From: Matt Mathis <[email-masked]>
Date: Thu, 22 Mar 2018 17:07:46 +0000

I would go one step further ... if there is any risk of harming BE, when
the DSCP is bleached or otherwise ineffective...

I prefer SHOULD, primarily to permit future techniques to audit that the
bits are honored and not bleached, or some future universe where the
network fully implements LE.  Also since LBE transports are known not to
share well with each other, we should assume that someday we may want to
expand our future CC options for LE.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.