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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF <
>>> [e-mail]<mailto:[e-mail]>> wrote:
>>>
>>>> So, just to follow up,
>>>>
>>>> On Mon, Feb 25, 2019 at 2:48 AM <[e-mail]<mailto:[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.
>>>
>>
>> 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".
>
> 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

I agree with Brian and also prefer the SHOULD NOT.

Regards,
 Roland

>> Spencer
>>
>>
>>>
>>>>    - Ruediger is thinking that SHOULD is the wrong answer, because that
>>>>    allows LE to be a "default below default"?
>>>>
>>>> W
>>>
>>>
>>>> Let's start and see if I got that right.
>>>>
>>>> Spencer
>>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> Ruediger
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: tsvwg <[e-mail]<mailto:[e-mail]>> Im Auftrag von BRUNGARD, DEBORAH A
>>>>> Gesendet: Samstag, 23. Februar 2019 17:33
>>>>> An: Roland Bless <[e-mail]<mailto:[e-mail]>>; Warren Kumari <
>>>>> [e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>>>>> 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.
>>>>>
>>>>> As Brian suggested, just keep the first part of the sentence.
>>>>>
>>>>> Thanks!
>>>>> Deborah
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Roland Bless <[e-mail]<mailto:[e-mail]>>
>>>>> Sent: Saturday, February 23, 2019 6:30 AM
>>>>> To: BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>; Warren Kumari <
>>>>> [e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>>>>> Subject: Re: [tsvwg] Warren Kumari's Discuss on
>>>>> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>>>>>
>>>>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Bless, Roland (TM)
>>>>>> Sent: Thursday, February 21, 2019 10:04 AM
>>>>>> To: Warren Kumari <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
>>>>>> Cc: David Black <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> 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
>>>
>>
>