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

[Warren Kumari <[e-mail]>]

Fine with me.

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

W

On Thu, Feb 28, 2019 at 6:27 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

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

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