Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
"Bless, Roland (TM)" <roland.bless@kit.edu> Thu, 28 February 2019 08:38 UTC
Return-Path: <roland.bless@kit.edu>
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 14510130F1F; Thu, 28 Feb 2019 00:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 RlEVsa79bJpv; Thu, 28 Feb 2019 00:38:44 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0A5130EE6; Thu, 28 Feb 2019 00:38:43 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1gzHDC-00088w-On; Thu, 28 Feb 2019 09:38:38 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id A154A420065; Thu, 28 Feb 2019 09:38:38 +0100 (CET)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 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>, 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> <ed05bc00-2532-3f45-6821-215073f49cc2@gmail.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <d9bec7c6-6950-f5c9-3f7a-c86db6ea02c9@kit.edu>
Date: Thu, 28 Feb 2019 09:38:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <ed05bc00-2532-3f45-6821-215073f49cc2@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1551343118.907503599
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/G7-Fdt9rGhto8bqBYk2QSsNrkGI>
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: Thu, 28 Feb 2019 08:39:00 -0000
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 <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 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 <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 >>> >> >
- [tsvwg] Warren Kumari's Discuss on draft-ietf-tsv… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Black, David
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Brian E Carpenter
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Black, David
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Brian E Carpenter
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Roland Bless
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Ruediger.Geib
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Brian E Carpenter
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Ruediger.Geib
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Gorry Fairhurst
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Ruediger.Geib
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Dave Taht
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Roland Bless
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Black, David