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

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Feb 2019 09:16:17 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-tsvwg-le-phb-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

----------------------------------------------------------------------
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.  "

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.

----------------------------------------------------------------------
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.)

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".

"However,using the Lower Effort PHB for multicast requires to pay special" --
"requires paying"...

---

From: "Black, David" <[email-masked]>
Date: Wed, 20 Feb 2019 19:27:39 +0000

Hi Warren,

> phone plans which are "unlimited", but after some amount of traffic (e.g., 22GB)

I believe the motivating scenario for this statement in the draft involves traffic that exceeds a bandwidth and/or burst limit, as opposed to a total data quantity (e.g., monthly) limit.  In particular, it would be bad for the tip of a burst spike to be downgraded to the LE PHB in the middle of a flow that otherwise uses a different PHB - the flow receiver may not be amused by the serious packet reordering that could result.

The scenario described above is different - I would say that traffic that exceeds a total data quantity (e.g., monthly) limit SHOULD NOT be downgraded to the LE PHB and (as you note) these cell phone plans obtain throttling via explicit rate limits.  The result when the monthly high-rate total data quantity limit is exceeded is not LE PHB behavior, because the customer's traffic is throttled even if the network has capacity available for that traffic.  Among the reasons for this operator behavior is to incentivize the customer to upgrade, e.g., to a 44GB monthly plan ;-). 

So, yes, that throttled traffic is "normal Internet" traffic, which has been rate-limited primarily for commercial reasons as opposed to network operational reasons.  The traffic remaining after the rate limit is applied is not appropriate for the LE PHB, and traffic in excess of the limit SHOULD not be downgraded, in order to avoid mixing the LE PHB with other PHBs in the same flow.

Is that explanation reasonable?

> But
> monitoring circuit utilization using e.g. interface counters (and not by traffic
> like it is 91% "full". I don't have any suggested text to address this (and

I would concur with your suggested answer, as adding support for a PHB in a network involves an explicit decision by the network operator - in general, see RFC 2475.

Thanks, --David

> -----Original Message-----
> From: Warren Kumari <[email-masked]>
> Sent: Wednesday, February 20, 2019 12:16 PM
> To: The IESG
> Cc: [email-masked]; Black, David; [email-masked];
> Black, David; [email-masked]
> Subject: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with
> DISCUSS and COMMENT)
> 
> 
> [EXTERNAL EMAIL]
> 
> phone plans which are "unlimited", but after some amount of traffic (e.g., 22GB)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2019 08:47:02 +1300

I agree with David, and I'll add one other point.

LE is a bit unusual in the diffserv model, in that logically it is
*only* the source node that can definitely know that traffic is of low
importance. So it simply makes no sense for a router later on the
path to re-classify a packet as LE; it can't have that knowledge.
That is rather different from other cases, such as router identifying
VOIP traffic and re-classifying it as EF.

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Feb 2019 14:31:32 -0800

On Wed, Feb 20, 2019 at 11:28 AM Black, David <[email-masked]> wrote:

> I believe the motivating scenario for this statement in the draft involves
> traffic that exceeds a bandwidth and/or burst limit, as opposed to a total
> data quantity (e.g., monthly) limit.  In particular, it would be bad for
> the tip of a burst spike to be downgraded to the LE PHB in the middle of a
> flow that otherwise uses a different PHB - the flow receiver may not be
> amused by the serious packet reordering that could result.
>
> The scenario described above is different - I would say that traffic that
> exceeds a total data quantity (e.g., monthly) limit SHOULD NOT be
> downgraded to the LE PHB and (as you note) these cell phone plans obtain
> throttling via explicit rate limits.

Me too!

The result when the monthly high-rate total data quantity limit is exceeded
> is not LE PHB behavior, because the customer's traffic is throttled even if
> the network has capacity available for that traffic.  Among the reasons for
> this operator behavior is to incentivize the customer to upgrade, e.g., to
> a 44GB monthly plan ;-).
>
> So, yes, that throttled traffic is "normal Internet" traffic, which has
> been rate-limited primarily for commercial reasons as opposed to network
> operational reasons.  The traffic remaining after the rate limit is applied
> is not appropriate for the LE PHB, and traffic in excess of the limit
> SHOULD not be downgraded, in order to avoid mixing the LE PHB with other
> PHBs in the same flow.
>

More than reasonable — but is it possible to put something in the document
like that?

W

> I would concur with your suggested answer, as adding support for a PHB in
> a network involves an explicit decision by the network operator - in
> general, see RFC 2475.
>
> Thanks, --David
>
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > this is just a comment, so "well, duh, they should know that anyway!" is
> a
> > fine
> > answer.)
> >
> > Nits:
> --
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: "Black, David" <[email-masked]>
Date: Thu, 21 Feb 2019 00:34:01 +0000

> More than reasonable — but is it possible to put something in the document like that?

Yes, that would certainly be reasonable ;-).

Thanks, --David

From: Warren Kumari <[email-masked]>
Sent: Wednesday, February 20, 2019 5:32 PM
To: Black, David
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

[EXTERNAL EMAIL]

On Wed, Feb 20, 2019 at 11:28 AM Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Hi Warren,

The scenario described above is different - I would say that traffic that exceeds a total data quantity (e.g., monthly) limit SHOULD NOT be downgraded to the LE PHB and (as you note) these cell phone plans obtain throttling via explicit rate limits.

Me too!

The result when the monthly high-rate total data quantity limit is exceeded is not LE PHB behavior, because the customer's traffic is throttled even if the network has capacity available for that traffic.  Among the reasons for this operator behavior is to incentivize the customer to upgrade, e.g., to a 44GB monthly plan ;-).

More than reasonable — but is it possible to put something in the document like that?

W

Thanks, --David

> From: Warren Kumari <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Black, David; [email-masked]<mailto:[email-masked]>;
> Black, David; [email-masked]<mailto:[email-masked]>
--
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: Warren Kumari <[email-masked]>
Date: Wed, 20 Feb 2019 16:41:04 -0800

> Yes, that would certainly be reasonable ;-).

I've cleared my DISCUSS, and will trust y'all to figure something out which
sounds sane.
W

>
>
> Thanks, --David
>
>
>
> *From:* Warren Kumari <[email-masked]>
> *Sent:* Wednesday, February 20, 2019 5:32 PM
> *To:* Black, David
> *Cc:* The IESG; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09:
> (with DISCUSS and COMMENT)
>
>
>
> [EXTERNAL EMAIL]
>
>
>
>
>
> The result when the monthly high-rate total data quantity limit is
> exceeded is not LE PHB behavior, because the customer's traffic is
> throttled even if the network has capacity available for that traffic.
> Among the reasons for this operator behavior is to incentivize the customer
> to upgrade, e.g., to a 44GB monthly plan ;-).
>
> a fine

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 21 Feb 2019 16:04:27 +0100

Hi Warren,

This was actually directly copied from RFC 3662.

> 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.

Thanks for the hint, valid point, but indeed: if they use Diffserv, they
should also monitor the resource shares for each PHB individually.

> implies singular.; I'd suggest "The main" or "A major".

Right.

> "However,using the Lower Effort PHB for multicast requires to pay special" --

Done.

Regards
 Roland

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 22 Feb 2019 17:14:16 +0000

>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:

"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.

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. 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)."

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"?

Thanks,
Deborah

-----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:
> 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.
> 

> 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.

> "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: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Feb 2019 08:13:11 +1300

Deborah,

> 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…

You are quite right. This is an unusual type of traffic compared with the general model for diffserv, where it's assumed that traffic can be re-classified at domain boundaries by some form of (possibly deep) packet inspection. In fact, only a sending host can know for sure that traffic is LE by nature.

So, downgrading any traffic to LE would seem to be always wrong. (Upgrading LE to BE would be less wrong but still might defeat the sender's intention.) IMHO deleting the "consent/knowledge" clause would be reasonable.

    Brian

---

From: Roland Bless <[email-masked]>
Date: Sat, 23 Feb 2019 12:30:03 +0100

Hi Deborah,

> 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 commen…

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.

> 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 sente…

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:

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 polic…

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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sat, 23 Feb 2019 16:32:49 +0000

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]
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Hi Deborah,

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."
> 

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…

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.

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 polic…

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

>> 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 
>> "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

---

From: <[email-masked]>
Date: Mon, 25 Feb 2019 08:47:45 +0000

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.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von BRUNGARD, DEBORAH A
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]
Betreff: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Hi Roland,

On your comment: 

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]
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Hi Deborah,

Best regards,
 Roland

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Feb 2019 14:16:57 -0600

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:
> 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
   - Ruediger is thinking that SHOULD is the wrong answer, because that
   allows LE to be a "default below default"?

Let's start and see if I got that right.

Spencer

> Betreff: Re: [tsvwg] Warren Kumari's Discuss on
> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>
> 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.
>
> Subject: Re: [tsvwg] Warren Kumari's Discuss on
> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>
> Hi Deborah,
>
> argument as hint: the >network lacks usually the application knowledge).
> >
> > 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:
>
> > 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.
>
> 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.
>
> 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.
>
> 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"?
>
> 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.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 27 Feb 2019 13:10:17 -0800

>    answer, because we don't tell operators how to mark traffic in their
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.

>> To: BRUNGARD, DEBORAH A <[email-masked]>; Warren Kumari <
>> [email-masked]>; The IESG <[email-masked]>
>> > 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.
>> >
>> > Thanks for the hint, valid point, but indeed: if they use Diffserv,
>> they should also monitor the resource shares for each PHB individually.
>> >
>> >> Nits:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Feb 2019 15:18:57 -0600

Hi, Warren,

On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari <[email-masked]> wrote:

>>> 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:

Given that no one around here gets paid by the BCP14 keyword ... when I've
gotten involved in previous conversations like this, one of the ways out
was not to SHOULD/MUST at all, but to explain clearly what happens if
someone does what they SHOULD NOT/MUST NOT do. Is that more helpful, or
more unhelpful?

I'll wait for Ruediger to surface, but I'm imagining that he might say "but
someone might say, that's only a SHOULD NOT, so I'm conforming to IETF
standards-track documents, so It Sucks To Be My Neighbor, but I don't
care".

Spencer

>>> An: Roland Bless <[email-masked]>; Warren Kumari <
>>> >> The main idea is that applications/users decide what traffic should
>>> 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.
>>>
>>> > "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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Feb 2019 10:44:46 +1300

> standards-track documents, so It Sucks To Be My Neighbor, but I don't

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.

   Brian

>>>> argument as hint: the >network lacks usually the application knowledge)..
>>>>>
>>>> they use LE as tool and downgrade users' traffic, they should say so, e..g.,
>>>>>> monitoring / management system so that they can see the traffic lass..

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 28 Feb 2019 09:38:38 +0100

Hi,

> doesn't much matter, but fwiw I'd probably prefer SHOULD NOT.

I agree with Brian and also prefer the SHOULD NOT.

Regards,
 Roland

---

From: <[email-masked]>
Date: Thu, 28 Feb 2019 08:38:49 +0000

I’m generally not happy with a standardised approach allowing to downgrade traffic from default to LE anywhere along an end-to-end path. That’s why I liked the approach, that LE marked traffic may be forwarded as LE only if it was received as LE. To me, default transport is what is delivered without negotiation (I hope not misinterpret ‘default’ here, I’m not a native speaker).

Of course, any carrier has the means to downgrade default traffic anywhere in his network. A standard specifying LE without prior notice makes the latter approach standard conformant.

Regards,

Ruediger

Von: Spencer Dawkins at IETF <[email-masked]>
Gesendet: Mittwoch, 27. Februar 2019 22:19
An: Warren Kumari <[email-masked]>
Cc: Geib, Rüdiger <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; IESG <[email-masked]>; Roland Bless <[email-masked]>; tsvwg-chairs <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Hi, Warren,

On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF <[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,

DISCUSSED CHANGE so far:

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.

Given that no one around here gets paid by the BCP14 keyword ... when I've gotten involved in previous conversations like this, one of the ways out was not to SHOULD/MUST at all, but to explain clearly what happens if someone does what they SHOULD NOT/MUST NOT do. Is that more helpful, or more unhelpful?

I'll wait for Ruediger to surface, but I'm imagining that he might say "but someone might say, that's only a SHOULD NOT, so I'm conforming to IETF standards-track documents, so It Sucks To Be My Neighbor, but I don't care".

Spencer

  *   Ruediger is thinking that SHOULD is the wrong answer, because that allows LE to be a "default below default"?
W

Spencer

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]<mailto:[email-masked]>> Im Auftrag von BRUNGARD, DEBORAH A
Gesendet: Samstag, 23. Februar 2019 17:33
An: Roland Bless <[email-masked]<mailto:[email-masked]>>; Warren Kumari <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Hi Roland,

On your comment:

Thanks!
Deborah

-----Original Message-----
From: Roland Bless <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, February 23, 2019 6:30 AM
To: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; Warren Kumari <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Hi Deborah,

Best regards,
 Roland

> From: iesg <[email-masked]<mailto:[email-masked]>> On Behalf Of Bless, Roland (TM)
> To: Warren Kumari <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: David Black <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Feb 2019 08:27:28 -0600

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:

> with
> neutrality
> with
> either
> go
> >>> I don't think the execution is relevant when it was obviously a bad
> idea
> >>> in the first place.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 28 Feb 2019 06:37:32 -0800

Fine with me.

As noted in the original DISCUSS, I'm fine with basically anything, just
wanted to ensure it had been considered.

W

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 28 Feb 2019 16:18:26 +0000

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)

Spencer

On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Am 27.02.19 um 22:44 schrieb Brian E Carpenter:
>>> [email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> So, just to follow up,
>>>>

Regards,
 Roland

>>>>> An: Roland Bless <[email-masked]<mailto:[email-masked]>>; Warren Kumari <
>>>>> [email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
>>>>> To: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; Warren Kumari <
>>>>> [email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Feb 2019 12:30:27 -0600

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