Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

[Gorry Fairhurst <[e-mail]>]

I have had a little reflexion on the discussion and I quite agree the 
following needs pruned/rewritten:

“However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to L, on a regular basis without consent or knowledge of the
user.”

     And I do agree with pruning this from the normative text:
     “on a regular basis without consent or knowledge of the
     user.”

     However, even though the original had become a little gabled,
     it was an attempt to capture that there *ARE* implications.
     We spent time talking about these implications in the WG and
     a lot of time trying to write text to avoid accidental remarking.

     I am still somewhat unclear how an operator could safely just map
     traffic to the LE   class, without a priori knowing what the flow
     expects. Sure, an operator could setup a BA-classifier and understand
     that application “X” wants this service. If it does that then that
     traffic will receive the treatment of LE traffic for the rest of the
     path. If I understood the intention, it was to remind people that
     this isn’t just another “lower level” in the diffserv hierarchy -
     traffic mapped to this class needs to be resilient to starvation,
     and expect that this will happen.

     I suggest an explanation could be added after the clause to be
     pruned to avoid this not working out well:

     “Remarking traffic from another PHB results in that traffic
     being "downgraded”. This changes the way the network treats this
     traffic and it is important not to violate the operational
     objectives of the original PHB.”

Gorry

P.S. Roland, I also just saw a few clauses saying “In case ....”, I don’t
know how I missed that in my review, but these read ambiguously to me: I
could it would be better if the phrase was “In the case that”.

On 28/02/2019, 18:30, Spencer Dawkins at IETF wrote:
> Thanks, Deborah!
>
> Roland, could you submit an updated version of this draft, so I can approve
> it before Wednesday of IETF 104? :-)
>
> Thanks,
>
> Spencer
>
> On Thu, Feb 28, 2019 at 10:18 AM BRUNGARD, DEBORAH A<[e-mail]>  wrote:
>
>> Yes, I’m ok with the abbreviated sentence as Warren and others suggested
>> “"Non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to LE."
>>
>>
>>
>> Thanks everyone-
>>
>> Deborah
>>
>>
>>
>> *From:* Spencer Dawkins at IETF<[e-mail]>
>> *Sent:* Thursday, February 28, 2019 9:27 AM
>> *To:* Bless, Roland (TM)<[e-mail]>
>> *Cc:* Brian E Carpenter<[e-mail]>; Warren Kumari<
>> [e-mail]>; [e-mail]; BRUNGARD, DEBORAH A<[e-mail]>;
>> IESG<[e-mail]>; tsvwg-chairs<[e-mail]>
>> *Subject:* Re: [tsvwg] Warren Kumari's Discuss on
>> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>>
>>
>>
>> So, Warren/Deborah, are we good on SHOULD NOT here?
>>
>>
>>
>> Spencer
>>
>>
>>
>> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM)<[e-mail]>
>> wrote:
>>
>> Hi,
>>
>> Am 27.02.19 um 22:44 schrieb Brian E Carpenter:
>>> On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote:
>>>> Hi, Warren,
>>>>
>>>> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari<[e-mail]>
>> wrote:
>>>>>
>>>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF<
>>>>> [e-mail]>  wrote:
>>>>>
>>>>>> So, just to follow up,
>>>>>>
>>>>>> On Mon, Feb 25, 2019 at 2:48 AM<[e-mail]>  wrote:
>>>>>>
>>>>>>> Deborah, Warren,
>>>>>>>
>>>>>>> IETF doesn't specify SLAs or related text, I agree. The LE
>> performance
>>>>>>> is worse than default forwarding. I'm unhappy if my peer demotes my
>> traffic
>>>>>>> to LE and points to an IETF standard allowing this.  What about:
>>>>>>>
>>>>>>> DISCUSSED CHANGE so far:
>>>>>>> Non-LE traffic (e.g., BE traffic) SHOULD NOT be
>>>>>>> remarked to LE on a regular basis.
>>>>>>>
>>>>>>> SOMEWHAT MORE PRECISELY DEFINED OPTION
>>>>>>> Non-LE traffic (e.g., BE traffic) MUST NOT be
>>>>>>> remarked to LE by default.
>>>>>>>
>>>>>>> I'd like to avoid LE to result in a "default below default" and
>> prefer
>>>>>>> IETF standards not allow fancy interpretations.
>>>>>>>
>>>>>> This document was approved on the last telechat, but we're having a
>>>>>> Discuss-level discussion about it now, which means that I should be
>> taking
>>>>>> this conversation very seriously (because "new technical objections
>> are
>>>>>> always in order").
>>>>>>
>>>>>> Am I understanding that
>>>>>>
>>>>>>     - Deborah (and, IIRC, Warren) are thinking that MUST is the wrong
>>>>>>     answer, because we don't tell operators how to mark traffic in
>> their
>>>>>>     networks, but
>>>>>>
>>>>>>
>>>>> Warren is thinking that, if you provide any sort of SHOULD/MUST
>> guidance
>>>>> regarding when it is appropriate to mark "abnormal" traffic, you have
>> to be
>>>>> able to define what you mean by normal and abnormal...
>>>>>
>>>>> Personally I would think that just: "Non-LE traffic (e.g., BE traffic)
>>>>> SHOULD NOT be remarked to LE." (or MUST NOT) without any qualifiers
>> would
>>>>> be best -- we are not the protocol police and don't have an enforcement
>>>>> arm, so we cannot really stop it. Where I think we run into trouble is
>>>>> saying "It is OK to do this on Thursdays when there is a half moon and
>> the
>>>>> wind blows from the South-East, but not at other times" (what if these
>> is
>>>>> only a slight breeze? Thursday where? or a waxing gibbous moon?) - I
>> think
>>>>> we should just say "You shouldn't remark",with the understanding that
>> some
>>>>> will and not open the "under these circumstances" can of worms at all