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

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Mar 2019 08:05:34 +0000

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<[email-masked]>  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<[email-masked]>
>> *Sent:* Thursday, February 28, 2019 9:27 AM
>> *To:* Bless, Roland (TM)<[email-masked]>
>> *Cc:* Brian E Carpenter<[email-masked]>; Warren Kumari<
>> [email-masked]>; [email-masked]; BRUNGARD, DEBORAH A<[email-masked]>;
>> IESG<[email-masked]>; tsvwg-chairs<[email-masked]>
>> *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)<[email-masked]>
>> 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<[email-masked]>
>> wrote:
>>>>>
>>>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF<
>>>>> [email-masked]>  wrote:
>>>>>
>>>>>> So, just to follow up,
>>>>>>
>>>>>> On Mon, Feb 25, 2019 at 2:48 AM<[email-masked]>  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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Mar 2019 08:15:02 -0500

>      objectives of the original PHB.”

That sounds reasonable to me....

W

> >> [email-masked]>; [email-masked]; BRUNGARD, DEBORAH A<[email-masked]
> >;
> >> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM)<[email-masked]
> >
> >> wrote:
> >>
> >> Hi,
> >>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 4 Mar 2019 20:38:45 +0000

Ok for me-
Deborah

From: iesg <[email-masked]> On Behalf Of Warren Kumari
Sent: Monday, March 04, 2019 8:15 AM
To: [email-masked]
Cc: [email-masked]; BRUNGARD, DEBORAH A <[email-masked]>; tsvwg-chairs <[email-masked]>; IESG <[email-masked]>; Bless, Roland (TM) <[email-masked]>; Brian E Carpenter <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

On Mon, Mar 4, 2019 at 3:05 AM Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:

     that application “X” wants this service.. If it does that then that

That sounds reasonable to me.....

W

Gorry

On 28/02/2019, 18:30, Spencer Dawkins at IETF wrote:
> On Thu, Feb 28, 2019 at 10:18 AM BRUNGARD, DEBORAH A<[email-masked]<mailto:[email-masked]>>  wrote:
>
>> *From:* Spencer Dawkins at IETF<[email-masked]<mailto:[email-masked]>>
>> *To:* Bless, Roland (TM)<[email-masked]<mailto:[email-masked]>>
>> *Cc:* Brian E Carpenter<[email-masked]<mailto:[email-masked]>>; Warren Kumari<
>> [email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BRUNGARD, DEBORAH A<[email-masked]<mailto:[email-masked]>>;
>> IESG<[email-masked]<mailto:[email-masked]>>; tsvwg-chairs<[email-masked]<mailto:[email-masked]>>
>> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM)<[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>> Hi,
>>
>>>> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari<[email-masked]<mailto:[email-masked]>>
>> wrote:
>>>>>
>>>>> [email-masked]<mailto:[email-masked]>>  wrote:
>>>>>
>>>>>> So, just to follow up,
>>>>>>
>>>>>> On Mon, Feb 25, 2019 at 2:48 AM<[email-masked]<mailto:[email-masked]>>  wrote:
>>>>>>
>>>>>>> Deborah, Warren,
>>>>>>>
>>>>>>> IETF standards not allow fancy interpretations..
>>>>>>>
--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Mar 2019 21:39:06 -0600

Hi, Gorry,

On Mon, Mar 4, 2019 at 2:39 PM BRUNGARD, DEBORAH A <[email-masked]> wrote:

> Ok for me-
>
> Deborah
>
>
>
>
>
> *From:* iesg <[email-masked]> *On Behalf Of * Warren Kumari
> *Sent:* Monday, March 04, 2019 8:15 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; BRUNGARD, DEBORAH A <[email-masked]>; tsvwg-chairs <
> [email-masked]>; IESG <[email-masked]>; Bless, Roland (TM) <
> [email-masked]>; Brian E Carpenter <[email-masked]>;
> Spencer Dawkins at IETF <[email-masked]>
> Thanks for sending your note. I knew there was an important point that was
trying to escape from the e-mail thread.

And NOW, I think, Roland can submit an approvable update.

Spencer

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 5 Mar 2019 09:49:19 +0100

Hi Spencer,

Am 05.03.19 um 04:39 schrieb Spencer Dawkins at IETF:

> Thanks for sending your note. I knew there was an important point that
> was trying to escape from the e-mail thread.
> 

I still have a backlog of IESG comments. However, I'll start
updating the draft and hope to submit it within the next
two days.

Regards
 Roland

---

From: <[email-masked]>
Date: Tue, 5 Mar 2019 13:19:01 +0000

Hi Gorry,

I agree to your proposal too.

Regards, Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von BRUNGARD, DEBORAH A
Gesendet: Montag, 4. März 2019 21:39
An: Warren Kumari <[email-masked]>; [email-masked]
Cc: tsvwg-chairs <[email-masked]>; [email-masked]; IESG <[email-masked]>; Bless, Roland (TM) <[email-masked]>
Betreff: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Ok for me-
Deborah

From: iesg <[email-masked]<mailto:[email-masked]>> On Behalf Of Warren Kumari
Sent: Monday, March 04, 2019 8:15 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; tsvwg-chairs <[email-masked]<mailto:[email-masked]>>; IESG <[email-masked]<mailto:[email-masked]>>; Bless, Roland (TM) <[email-masked]<mailto:[email-masked]>>; Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

W

Gorry

---

From: Dave Taht <[email-masked]>
Date: Sun, 10 Mar 2019 15:00:47 -0700

<[email-masked]> writes:

> Deborah, Warren,
>
> IETF doesn't specify SLAs or related text, I agree. The LE performance
> traffic to LE and points to an IETF standard allowing this.  What
> about:
>
> DISCUSSED CHANGE so far:
> I'd like to avoid LE to result in a "default below default" and prefer

I would prefer even stronger language than the above in this document.

I have noted elsewhere that Comcast, at least, remarks *all* traffic it
does not recognize to CS1 - when last I checked. This plays merry hell
when diffserv is not washed out when it crosses into the home, and
particularly wifi. While I would prefer they not fiddle with the bits at all...

Precisely defined option:

Non-LE traffic MUST NOT be remarked to LE.

I might be willing to put in a caveat like:

"unless the transit provider has extremely compelling reasons to have
identified this traffic to be intended to cause harm, e.g. a DDOS
attempt."

>
> Regards,
>
> Ruediger
>
> -----Ursprüngliche Nachricht-----
> Gesendet: Samstag, 23. Februar 2019 17:33
> An: Roland Bless <[email-masked]>; Warren Kumari <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Hi Roland,
> On your comment: 
> "In former times P2P file sharing traffic was throttled by some ISPs
> without telling the users. The danger is that the same thing happens
> with remarking traffic as LE, so IMHO the user should be informed at
> least that traffic is downgraded. Maybe consent is too strong, so I
> propose to delete "consent", but stay with "without knowledge of the
> user" or I will rephrase it accordingly. However, it's still a SHOULD
> NOT only."
>
> I can not comment on what some ISPs do and what is in their service
> contracts. I am fine with this as a "SHOULD NOT". I am not fine with
> saying anything about what a service operator needs to do regarding a
> service contract. IETF hasn't in the past made these statements (btw -
> ITU-T does not touch this either). Hint: I don't think pointing to
> this RFC will help you.
>
> As Brian suggested, just keep the first part of the sentence.
>
> Thanks!
> Deborah
>
>
> -----Original Message-----
> From: Roland Bless <[email-masked]>
> Sent: Saturday, February 23, 2019 6:30 AM
> To: BRUNGARD, DEBORAH A <[email-masked]>; Warren Kumari <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Hi Deborah,
> On 22.02.19 at 18:14 BRUNGARD, DEBORAH A wrote:
>>> The main idea is that applications/users decide what traffic should
>>> go to the "background", i.e., which packet are marked as LE
>>> (end-to-end argument as hint: the >network lacks usually the
>>> application knowledge).
>> 
>> I'll take the opportunity to jump in here😊
>> 
>> This was my comment, I was confused, as there's a couple of places
>> in this document which infer much more than previous RFCs on what a
>> "user" can do vs. what a network operator can do. In my comment, I
>> noted the sentence:
>
> Sorry, for causing confusion :-)
> I was trying to answer the IESG comments one by one and didn't arrive at yours yet, so I also jump in.
>
>> "However, non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to 
>> LE on a regular basis without consent or knowledge of the user."
>> 
>> I scanned other RFCs, I don't see this requirement that an operator needs to have the consent/knowledge of the user before remarking? Suggest simply dropping the "without consent..." from the sentence.
>
> Your impression is probably right that this is not really consistent, because some of the text stems from RFC 3662 and some was added within this I-D.
> At the time of RFC 3662, the view was probably more toward: LE is mainly a tool for network operators.
> Yes, it is, but it's also a different question _who_ is actually deciding what traffic is classified as LE. In the light of net neutrality debates, it would be fair if the user classifies its traffic as LE if it is eligible and I find it reasonable that providers should be transparent: if they use LE as tool and downgrade users' traffic, they should say so, e.g., inform the user that they downgrade under certain conditions.
>
> In former times P2P file sharing traffic was throttled by some ISPs without telling the users. The danger is that the same thing happens with remarking traffic as LE, so IMHO the user should be informed at least that traffic is downgraded. Maybe consent is too strong, so I propose to delete "consent", but stay with "without knowledge of the user" or I will rephrase it accordingly. However, it's still a SHOULD NOT only.
>
>> And the sentence in the abstract "Ideally, applications mark their packets as LE traffic, since they know the urgency of flows." You answered Warren "The main idea is that applications/users decide what traffic should go to the "background", i.e., which packet are marked as LE (end-to-end argument..". This is very confusing as it contradicts other RFCs where marking/re-markings are tools for a network operator. 
>
> Besides the net-neutrality argument, the e2e argument is another good reason to only let user decide, what should go into this class. The user cannot harm the network this way, so there is no reason for the Diffserv domain to distrust this marking coming from the end-system.
> For other Diffserv PHBs this IS different, because they are elevated services (i.e., better than best-effort): a Diffserv domain should either do the initial marking or at least apply policing at the ingress boundary nodes - otherwise QoS guarantees may be at risk; here the markings from end-systems cannot be trusted at least policing is required that may include re-marking. So for the EF PHB for example, admission control and policing are essential.
>
>> It directly contradicts RFC8325/section 5.4:
>> "An alternative option to mapping is for the administrator to treat the wireless edge as the edge of the Diffserv domain and explicitly set (or reset) DSCP markings in the upstream direction according to administrative policy.  This option is RECOMMENDED over mapping, as this typically is the most secure solution because the network administrator directly enforces the Diffserv policy across the IP network (versus an application developer and/or the developer of the operating system of the wireless endpoint device, who may be functioning completely independently of the network administrator)."
>
> Yes, that's exactly what I explained in the preceding text above:
> normally a Diffserv domain must strictly protect its network at the boundary.
>
>> I recognize this RFC maintains "no harm" saying "There is no incentive for DS domains to distrust this initial marking, because letting LE traffic enter a DS domain causes no harm.  Thus, any policing such as limiting the rate of LE traffic is not necessary at the DS boundary." I'm a bit nervous on that assumption, I think most operators would agree with Warren's title, "hysterical raisins"😊 Can IETF really maintain (this is PS), "no worries"?
>
> Maybe I don't get the point. Under the assumption that this LE traffic would have been injected as normal default BE traffic otherwise, I don't see any negative consequences for the provider. It is a different thing if the user would refrain from injecting this traffic, because he/she wants to really only transmit this as background/scavenger traffic.
> But compared to the alternative that this traffic would traverse the domain as BE traffic otherwise, I would confirm the "no worries"
> property.
>
> Best regards,
>  Roland
>
>> -----Original Message-----
>> From: iesg <[email-masked]> On Behalf Of Bless, Roland (TM)
>> Sent: Thursday, February 21, 2019 10:04 AM
>> To: Warren Kumari <[email-masked]>; The IESG <[email-masked]>
>> Cc: David Black <[email-masked]>; [email-masked]; 
>> [email-masked]
>> Subject: Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: 
>> (with DISCUSS and COMMENT)
>> 
>> Hi Warren,
>> 
>> Am 20.02.19 um 18:16 schrieb Warren Kumari:
>>> ---------------------------------------------------------------------
>>> -
>>> DISCUSS:
>>> ---------------------------------------------------------------------
>>> -
>>>
>>> I believe that this should be trivial DISCUSS to address, but I 
>>> thought it important enough to warrant it. I'm OK with basically 
>>> whatever you answer, I just wanted to make sure this had been seen and considered.
>>>
>>> "An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
>>>    traffic nor should packets be "downgraded" to the LE PHB instead of
>>>    being dropped, particularly when the packets are unauthorized
>>>    traffic.  "
>> 
>> This was actually directly copied from RFC 3662.
>> 
>>> Great, sounds good to me -- but in the USA at least, there is are 
>>> many cell phone plans which are "unlimited", but after some amount of 
>>> traffic (e.g 22GB) your connection gets throttled to a lower data 
>>> rate. Is this traffic still 'a customer's "normal Internet" traffic"?
>>> Is it appropriate (whatever that means) to downgrade this traffic to 
>>> the LE PHB? I understand not wanting to touch this issue with  a 10 
>>> foot pole (and I don't know what the right answer is!), but you *did* 
>>> open this can of worms by talking about what classification user traffic should have.
>>>
>>> Note: I'm happy to clear my DISCUSS no matter what the answer is, I 
>>> just want to make sure it has been considered / discussed.
>> 
>> The main idea is that applications/users decide what traffic should
>> go to the "background", i.e., which packet are marked as LE
>> (end-to-end argument as hint: the network lacks usually the
>> application knowledge).
>> Operators must have good reasons to deliberately downgrade users'
>> normal traffic. In case of throttled traffic, this would still be
>> considered as being normal BE traffic. One case for downgrading BE
>> traffic could be non-admitted multicast replication traffic as
>> described in RFC 3754.
>> 
>>> ---------------------------------------------------------------------
>>> -
>>> COMMENT:
>>> ---------------------------------------------------------------------
>>> -
>>>
>>> Major:
>>> "Some network providers keep link utilization below 50% to ensure 
>>> that all traffic is forwarded without loss after rerouting caused by 
>>> a link failure (cf.Section 6 of [RFC3439]).  LE marked traffic can 
>>> utilize the normally unused capacity and will be preempted 
>>> automatically in case of link failure when 100% of the link capacity 
>>> is required for all other traffic. " Yup - very true. But I think it 
>>> needs to be mentioned that the provider will need to upgrade their 
>>> monitoring / management system so that they can see the traffic lass.
>>> If they monitoring circuit utilization using e.g interface counters 
>>> (and not by traffic class), a link may have 1% "real" traffic and 90% 
>>> LE traffic, and it will look like it it 91% "full". I don't have any 
>>> suggested text to address this (and this is just a comment, so "well, 
>>> duh, they should know that anyway!" is a fine
>>> answer.)
>> 
>> Thanks for the hint, valid point, but indeed: if they use Diffserv,
>> they should also monitor the resource shares for each PHB
>> individually.
>> 
>>> Nits:
>>> "A main problem is that multicast" -- I'm not sure you can say "A 
>>> main" - main implies singular.; I'd suggest "The main" or "A major".
>> 
>> Right.
>> 
>>> "However,using the Lower Effort PHB for multicast requires to pay 
>>> special" -- "requires paying"...
>> 
>> Done.
>> 
>> Regards
>>  Roland
>>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 11 Mar 2019 14:34:42 +0100

Hi Spencer,

Am 28.02.19 um 19:30 schrieb Spencer Dawkins at IETF:
> Roland, could you submit an updated version of this draft, so I can
> approve it before Wednesday of IETF 104? :-) 

Somewhat later than planned, but draft v10 has just been posted.
It should cover all IESG comments (unless I overlooked something).

Name:		draft-ietf-tsvwg-le-phb
Revision:	10
Title:		A Lower Effort Per-Hop Behavior (LE PHB) for Differentiated Services
Document date:	2019-03-11
Group:		tsvwg
Pages:		21
URL:
https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-le-phb-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-10
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-le-phb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-10

Regards
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 12 Mar 2019 23:58:00 +0100

Hi Dave,

Brian Carpenter wrote:

>>> We all know that SHOULD NOT means MUST NOT unless there's a compelling
>>> reason to do otherwise, and we all know that implementers and operators
>>>> have no trouble finding a compelling reason when they want to. So
it actually
>>>> doesn't much matter, but fwiw I'd probably prefer SHOULD NOT.

and I agree with this view.

> particularly wifi. While I would prefer they not fiddle with the bits at all...

They SHOULD NOT do this.

> Non-LE traffic MUST NOT be remarked to LE.

Ok, in the latest draft version -10 I chose to
use what Gorry proposed:
   However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
   remarked to LE.  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.

> identified this traffic to be intended to cause harm, e.g. a DDOS

If the traffic is known to cause harm the draft says it SHOULD be
dropped rather than being downgraded:
                                                    An LE PHB SHOULD NOT
   be used for a customer's "normal Internet" traffic and packets SHOULD
   NOT be "downgraded" to the LE PHB instead of being dropped,
   particularly when the packets are unauthorized traffic.

but it also says:
                               LE ought not to be used for the general
   case of downgraded traffic, but could be used by design, e.g., to
   protect an internal network from untrusted external traffic sources.

Regards,
 Roland

---

From: "Black, David" <[email-masked]>
Date: Wed, 13 Mar 2019 04:51:43 +0000

Hi Dave,

> identified this traffic to be intended to cause harm, e.g. a DDOS

Well, "MUST NOT" does allow the opportunity for an "unless ..." escape clause - see RFC 2119.  So the right way to express your intent (as I understand it) is as "SHOULD NOT" ... which is what's in the -10 version along with some explanatory text in section 5:

I suspect that bleaching (remarking LE to BE) is going to be a bigger problem in practice, and that's also a "SHOULD NOT" requirement.

I hope that new text in Section 5 suffices, including the mention of network operational impact.

Thanks, --David

> From: tsvwg <[email-masked]> On Behalf Of Dave Taht
> Sent: Sunday, March 10, 2019 6:01 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> [EXTERNAL EMAIL]
> > An: Roland Bless <[email-masked]>; Warren Kumari
> <[email-masked]>; The IESG <[email-masked]>
> > To: BRUNGARD, DEBORAH A <[email-masked]>; Warren Kumari
> <[email-masked]>; The IESG <[email-masked]>
> >> I scanned other RFCs, I don't see this requirement that an operator needs to
> have the consent/knowledge of the user before remarking? Suggest simply
> dropping the "without consent..." from the sentence.
> >
> > Your impression is probably right that this is not really consistent, because
> some of the text stems from RFC 3662 and some was added within this I-D.
> > Yes, it is, but it's also a different question _who_ is actually deciding what
> traffic is classified as LE. In the light of net neutrality debates, it would be fair if
> the user classifies its traffic as LE if it is eligible and I find it reasonable that
> providers should be transparent: if they use LE as tool and downgrade users'
> traffic, they should say so, e.g., inform the user that they downgrade under
> certain conditions.
> >
> > In former times P2P file sharing traffic was throttled by some ISPs without
> telling the users. The danger is that the same thing happens with remarking
> traffic as LE, so IMHO the user should be informed at least that traffic is
> downgraded. Maybe consent is too strong, so I propose to delete "consent", but
> stay with "without knowledge of the user" or I will rephrase it accordingly.
> However, it's still a SHOULD NOT only.
> >
> >> And the sentence in the abstract "Ideally, applications mark their packets as
> LE traffic, since they know the urgency of flows." You answered Warren "The
> main idea is that applications/users decide what traffic should go to the
> "background", i.e., which packet are marked as LE (end-to-end argument..". This
> is very confusing as it contradicts other RFCs where marking/re-markings are
> tools for a network operator.
> >
> > Besides the net-neutrality argument, the e2e argument is another good reason
> to only let user decide, what should go into this class. The user cannot harm the
> network this way, so there is no reason for the Diffserv domain to distrust this
> marking coming from the end-system.
> > For other Diffserv PHBs this IS different, because they are elevated services
> (i.e., better than best-effort): a Diffserv domain should either do the initial
> marking or at least apply policing at the ingress boundary nodes - otherwise QoS
> guarantees may be at risk; here the markings from end-systems cannot be
> trusted at least policing is required that may include re-marking. So for the EF
> PHB for example, admission control and policing are essential.
> >
> >> "An alternative option to mapping is for the administrator to treat the
> wireless edge as the edge of the Diffserv domain and explicitly set (or reset)
> DSCP markings in the upstream direction according to administrative policy.  This
> option is RECOMMENDED over mapping, as this typically is the most secure
> solution because the network administrator directly enforces the Diffserv policy
> across the IP network (versus an application developer and/or the developer of
> the operating system of the wireless endpoint device, who may be functioning
> completely independently of the network administrator).."
> >
> >> I recognize this RFC maintains "no harm" saying "There is no incentive for DS
> domains to distrust this initial marking, because letting LE traffic enter a DS
> domain causes no harm.  Thus, any policing such as limiting the rate of LE traffic
> is not necessary at the DS boundary." I'm a bit nervous on that assumption, I
> think most operators would agree with Warren's title, "hysterical raisins"😊 Can
> IETF really maintain (this is PS), "no worries"?
> >
> > Maybe I don't get the point. Under the assumption that this LE traffic would
> have been injected as normal default BE traffic otherwise, I don't see any
> negative consequences for the provider. It is a different thing if the user would
> refrain from injecting this traffic, because he/she wants to really only transmit
> this as background/scavenger traffic.
> > But compared to the alternative that this traffic would traverse the domain as
> BE traffic otherwise, I would confirm the "no worries"
> > property.
> >
> > Best regards,
> >  Roland
> >