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

"Black, David" <David.Black@dell.com> Wed, 20 February 2019 19:28 UTC

Return-Path: <David.Black@dell.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 A7218130E58; Wed, 20 Feb 2019 11:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.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 LXRuM3eX0p1n; Wed, 20 Feb 2019 11:28:22 -0800 (PST)
Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 C510E129C6A; Wed, 20 Feb 2019 11:28:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1550690902; x=1582226902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y9gPA7I59KDmln4eMV724SIQcN9F2bzRGJv/6lGO0FY=; b=0S7lF8BYQSkZ616RahyXSLTR6sIbo4xiHSGY2oD05q686pURQYT4wfxb ImaoVorm2hwVOXpk6foKaBjWp/aZM7SxM73WNJH0e66yy3kvDjzNq5JWa qe044TTtoYpt7Uar7/O4bn5BCPNNAH3HgiEPSLWDNrcaIdg/E0v210mjT g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ETAQChqW1chieV50NkHAEBAQQBAQcEAQGBZYExJIEFEYEDJwqDfYh5jRh8lzSBZwsBASMLhD4CF4NeIjgSAQMBAQIBAQIBAQIQAQEBCgkLCCkjDII6KQEUMRw+AQEBAQEBJwEBAQEBASMCRCwBAQEBAgESERErGgUHBAIBCBEEAQEDAgYgAgICMBUICAIEAQ0FCBqCfgGBaggBDqF/PQJtgQGJBwEBAW+BL4RDQYUpBYELizmBWD6BEUaCFzWDHgIBAgGBKgEBCgEGASEVgnIxgiYCiWYkL5kTAwQCAoc6g2+HSIFwhVeLP4pHhU2MNwIEAgQFAhSBXoEHWBEIcIM8gigOCROITIU/QTEBjT0BDheBCIEfAQE
X-IPAS-Result: A2ETAQChqW1chieV50NkHAEBAQQBAQcEAQGBZYExJIEFEYEDJwqDfYh5jRh8lzSBZwsBASMLhD4CF4NeIjgSAQMBAQIBAQIBAQIQAQEBCgkLCCkjDII6KQEUMRw+AQEBAQEBJwEBAQEBASMCRCwBAQEBAgESERErGgUHBAIBCBEEAQEDAgYgAgICMBUICAIEAQ0FCBqCfgGBaggBDqF/PQJtgQGJBwEBAW+BL4RDQYUpBYELizmBWD6BEUaCFzWDHgIBAgGBKgEBCgEGASEVgnIxgiYCiWYkL5kTAwQCAoc6g2+HSIFwhVeLP4pHhU2MNwIEAgQFAhSBXoEHWBEIcIM8gigOCROITIU/QTEBjT0BDheBCIEfAQE
Received: from mx0a-00154901.pphosted.com ([67.231.149.39]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 20 Feb 2019 13:28:04 -0600
Received: from pps.filterd (m0134746.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1KJN9Ba182053; Wed, 20 Feb 2019 14:28:04 -0500
Received: from esa2.dell-outbound2.iphmx.com (esa2.dell-outbound2.iphmx.com [68.232.153.202]) by mx0a-00154901.pphosted.com with ESMTP id 2qsa5ph7cj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 14:27:57 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 21 Feb 2019 01:27:48 +0600
Received: from maildlpprd01.lss.emc.com ([10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x1KJRqwA030247 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Feb 2019 14:27:54 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x1KJRqwA030247
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 20 Feb 2019 14:27:38 -0500
Received: from MXHUB306.corp.emc.com ([10.146.3.32]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x1KJRdO0027579 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 20 Feb 2019 14:27:40 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0415.000; Wed, 20 Feb 2019 14:27:39 -0500
To: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tsvwg-le-phb@ietf.org" <draft-ietf-tsvwg-le-phb@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
Thread-Index: AQHUyUAKmWTi2iDqEkuy0jwJCVVOmKXpCxNg
Date: Wed, 20 Feb 2019 19:27:39 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363046559E@MX307CL04.corp.emc.com>
References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com>
In-Reply-To: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.131]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-20_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902200133
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/M9H7t4Skgk6DR9pIjf9lc7IqDpo>
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, 20 Feb 2019 19:28:25 -0000

Hi Warren,

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

I believe the motivating scenario for this statement in the draft involves traffic that exceeds a bandwidth and/or burst limit, as opposed to a total data quantity (e.g., monthly) limit.  In particular, it would be bad for the tip of a burst spike to be downgraded to the LE PHB in the middle of a flow that otherwise uses a different PHB - the flow receiver may not be amused by the serious packet reordering that could result.

The scenario described above is different - I would say that traffic that exceeds a total data quantity (e.g., monthly) limit SHOULD NOT be downgraded to the LE PHB and (as you note) these cell phone plans obtain throttling via explicit rate limits.  The result when the monthly high-rate total data quantity limit is exceeded is not LE PHB behavior, because the customer's traffic is throttled even if the network has capacity available for that traffic.  Among the reasons for this operator behavior is to incentivize the customer to upgrade, e.g., to a 44GB monthly plan ;-). 

So, yes, that throttled traffic is "normal Internet" traffic, which has been rate-limited primarily for commercial reasons as opposed to network operational reasons.  The traffic remaining after the rate limit is applied is not appropriate for the LE PHB, and traffic in excess of the limit SHOULD not be downgraded, in order to avoid mixing the LE PHB with other PHBs in the same flow.

Is that explanation reasonable?

> 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 is 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.)

I would concur with your suggested answer, as adding support for a PHB in a network involves an explicit decision by the network operator - in general, see RFC 2475.

Thanks, --David

> -----Original Message-----
> From: Warren Kumari <warren@kumari.net>
> Sent: Wednesday, February 20, 2019 12:16 PM
> To: The IESG
> Cc: draft-ietf-tsvwg-le-phb@ietf.org; Black, David; tsvwg-chairs@ietf.org;
> Black, David; tsvwg@ietf.org
> Subject: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with
> DISCUSS and COMMENT)
> 
> 
> [EXTERNAL EMAIL]
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-tsvwg-le-phb-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/
> 
> 
> 
> ----------------------------------------------------------------------
> 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.  "
> 
> 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.
> 
> 
> ----------------------------------------------------------------------
> 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.)
> 
> 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".
> 
> "However,using the Lower Effort PHB for multicast requires to pay special" --
> "requires paying"...
>