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

[Spencer Dawkins at IETF <[e-mail]>]

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