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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 27 February 2019 21:44 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984A131169; Wed, 27 Feb 2019 13:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF0uDOVqJn-Y; Wed, 27 Feb 2019 13:44:49 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F71613115E; Wed, 27 Feb 2019 13:44:49 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id v21so8618711pfm.12; Wed, 27 Feb 2019 13:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6GrK8I4TPg41nBIGrqg9W04a0EomRJAiMLmzYehrFh0=; b=J5NNf9LHfhsSq2Bwn/u1Wn2GcbobIDZTbVlXhxOYZRuXQO0r87498KYANZBllzGPmH kc2IxEElXrg/En+fAK4RDQNkT1crwL7xlEfQe03xgYgozMxfr2SpJ6CTkH0mGaa0ycMf YsfBq4bQ1RZ/C5y9z9XQMzZP77uqSd946NMtdD6qM6MOCjwWQudugCLwskPFeVyydppl VufA6HZv9xR9+VRCAnzHNAGDAKorz50f5gRGqrICqgjLs2e5InJOhBoI24q/KwJbbxPz vZOZcFX4nHh94yFhnR+11qNStCdXM4SXkwlpn1z8TtLhaVZ/BNPiUHnd//OYTDYce3Io JNfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6GrK8I4TPg41nBIGrqg9W04a0EomRJAiMLmzYehrFh0=; b=XBJ4XFYpI4aBosJbZJhOIaowypcmQVEoAavAzCVEqoFsiDBgvfT6KG8OqM2PgysgyT SiMrk+tRdICkpdDcXF6Zzo1D4YKscaE937y6cRXYrbYOZPb/ppRB395I1PeFKohQL0Cm zwp0q/97EJl6sc4Vmr61K7/cAdxGLPbCQbvDY3H6kQHO2oH6KMUc5sIb6KCHdoaEKlbY 025eAYHEIgVDXoAvIGOTenuwwbEAMMZlipLGN3hDT+JBF0kWjr+//8CC8buuSPcL6tca nip0w6bhP0dVgP4c2T738CJcQa6zsL8QgtQxAMyrYZdl0uyK4A4f2yWGhdYtSVH1HNUb 6gBA==
X-Gm-Message-State: AHQUAubOmgulJEde+FZm5G5eJ9piOsUhzBYmOGJKyAHfRDNAQ5pX9wU0 czsNDbhgk9JjBZcO1XOd8JnHQ6RN
X-Google-Smtp-Source: AHgI3IZCZTBB4TbCaLlwUtHSKaq5m9HSjAi9MOwN9LpQvma1zMTa9HJysOZzGLVtleLm+BkMyevCzA==
X-Received: by 2002:a63:360e:: with SMTP id d14mr5092967pga.179.1551303888253; Wed, 27 Feb 2019 13:44:48 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id s80sm11759931pgs.4.2019.02.27.13.44.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 13:44:47 -0800 (PST)
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Warren Kumari <warren@kumari.net>
Cc: tsvwg@ietf.org, "BRUNGARD, DEBORAH A" <db3546@att.com>, IESG <iesg@ietf.org>, Roland Bless <roland.bless@kit.edu>, tsvwg-chairs <tsvwg-chairs@ietf.org>
References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <F64C10EAA68C8044B33656FA214632C89EF79DEE@MISOUT7MSGUSRDE.ITServices.sbc.com> <f38b43e8-d300-f44f-1f84-f7652e4f36e2@kit.edu> <F64C10EAA68C8044B33656FA214632C89EF7B8F6@MISOUT7MSGUSRDE.ITServices.sbc.com> <LEJPR01MB04609C8FCFADC32676FE0AB29C7A0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CAKKJt-dQjobkMSKSRenMK3VeEQeny-cZb321dEu5trYCBx5ptg@mail.gmail.com> <CAHw9_iL=aSzLWGL8R4zu1Z4QbNeFHoFgozUPANUYGatm-LpZPg@mail.gmail.com> <CAKKJt-e+6OmqG3EcGwd+92YnL-a=Ry+ymYORdwgO0cxgb1FU6Q@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ed05bc00-2532-3f45-6821-215073f49cc2@gmail.com>
Date: Thu, 28 Feb 2019 10:44:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CAKKJt-e+6OmqG3EcGwd+92YnL-a=Ry+ymYORdwgO0cxgb1FU6Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HZxbq7t59HT3x1Fc0LJSCN_rIsI>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 21:44:53 -0000

On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote:
> Hi, Warren,
> 
> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari <warren@kumari.net> wrote:
> 
>>
>>
>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>>> So, just to follow up,
>>>
>>> On Mon, Feb 25, 2019 at 2:48 AM <Ruediger.Geib@telekom.de> 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

> 
> 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 <tsvwg-bounces@ietf.org> Im Auftrag von BRUNGARD, DEBORAH A
>>>> Gesendet: Samstag, 23. Februar 2019 17:33
>>>> An: Roland Bless <roland.bless@kit.edu>; Warren Kumari <
>>>> warren@kumari.net>; The IESG <iesg@ietf.org>
>>>> Cc: tsvwg-chairs@ietf.org; tsvwg@ietf.org
>>>> 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 <roland.bless@kit.edu>
>>>> Sent: Saturday, February 23, 2019 6:30 AM
>>>> To: BRUNGARD, DEBORAH A <db3546@att.com>; Warren Kumari <
>>>> warren@kumari.net>; The IESG <iesg@ietf.org>
>>>> Cc: tsvwg-chairs@ietf.org; tsvwg@ietf.org
>>>> 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 <iesg-bounces@ietf.org> On Behalf Of Bless, Roland (TM)
>>>>> Sent: Thursday, February 21, 2019 10:04 AM
>>>>> To: Warren Kumari <warren@kumari.net>; The IESG <iesg@ietf.org>
>>>>> Cc: David Black <david.black@dell.com>; tsvwg-chairs@ietf.org;
>>>>> tsvwg@ietf.org
>>>>> 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
>>
>