Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019
"Black, David" <David.Black@dell.com> Tue, 09 July 2019 23:51 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 59388120089; Tue, 9 Jul 2019 16:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=OQwxttwe; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=SnYIWyUS
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 b6ADBvnt9nZh; Tue, 9 Jul 2019 16:51:31 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 BEBDA120020; Tue, 9 Jul 2019 16:51:31 -0700 (PDT)
Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x69NoWcY009445; Tue, 9 Jul 2019 19:50:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=CuTAS0Vio6UfyO+dt+2JcWb3joKh/ElpO7Nvy1jCe1Q=; b=OQwxttweteBY53/I0sUZIM37FEf+BqNJmWVsmOzNlX2wvWQViEMud104r6rEsuflZonf d+Dz4RQ142OGHWhY0zpN0lwHPV1LiqGKzC7gSZnqqeUTTGy36R2QFIGpMWcWFT2Fh2ZU 1bAnbX4bqC0YVEBmkS5DCqY59TXj37B2ZJH4km44K+PstCcZQUAv74KR6Q3q8ITS0i17 nA4kvwXe4dy8XP3/3dmMYpOAZ0H06A4UNWa+99RFPPQrQZPP6dF33OYGNA0o8++8DDN7 ah5eVuSVQIKV7A8I2Wtv43SIrkE1UsBnO0FbOw1s3ncR1xB4xc2ygRM2qwc8SbAT39Sv +Q==
Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2tmpb7v3ee-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Jul 2019 19:50:47 -0400
Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x69NljLh075302; Tue, 9 Jul 2019 19:50:46 -0400
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2tn214jy5m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 09 Jul 2019 19:50:45 -0400
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x69NogIF026409 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jul 2019 19:50:44 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x69NogIF026409
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1562716244; bh=4ud0adrhG42d9FP7hlVIMoo+Hlw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=SnYIWyUS7K3CY+JRL4xRny/IOJ1i05/wxfx3MNo5pv59eWlDsh7H7jPG59Lf2Q/oe lu+Q3VOO2kIgxzwUoUyVvZTMyefsS1KU50LNAg7UPARO060G4bdX/Imwir7CKoHH/9 9cPmZC/h7BmFKS5nHFafOVfBD4nftTNaJx0ryIOU=
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 9 Jul 2019 19:50:17 -0400
Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x69NoH2R005749 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 9 Jul 2019 19:50:17 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 19:50:17 -0400
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, Joe Touch <touch@strayalpha.com>
CC: "int-area@ietf.org" <int-area@ietf.org>, tsvwg <tsvwg@ietf.org>
Thread-Topic: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019
Thread-Index: AQHU/Ryci9ghgFlev0m4sdzxWan0KKZuoYSAgFK4doCAAg0k8A==
Date: Tue, 09 Jul 2019 23:50:16 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363060E56D@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949363052958E@MX307CL04.corp.emc.com> <598B8434-3B6D-434A-B963-7FEE04D9770B@strayalpha.com> <70abde72-0091-66e3-b819-ad839e1fd028@bobbriscoe.net> <d7252ffe-e13c-243c-efa2-bb15e67bd758@bobbriscoe.net>
In-Reply-To: <d7252ffe-e13c-243c-efa2-bb15e67bd758@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-09T23:48:47.4776104Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.238.21.131]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363060E56DMX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-09_09:, , 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=1011 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-1907090285
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 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-1907090285
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_AzJWM94HBmmHmo-7Z8IVa0jOkU>
Subject: Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019
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: Tue, 09 Jul 2019 23:51:36 -0000
Bob, In this text: On average, a tunnel egress SHOULD approximately preserve the number of CE-marked and ECT(1)-marked octets arriving and leaving ... I understand the rationale for CE-marked octets, but what’s the rationale for ECT(1)-marked octets? Thanks, --David From: Bob Briscoe <ietf@bobbriscoe.net> Sent: Monday, July 8, 2019 8:28 AM To: Joe Touch; Black, David Cc: int-area@ietf.org; tsvwg Subject: Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019 [EXTERNAL EMAIL] Joe, Following up my email to you in May quoted further down, you made me realize that RFC6040 did not address what to do with ECN during fragmentation and reassembly. So I've added the following to my local copy of draft-ietf-tsvwg-rfc6040-update-shim (to be posted later today), which recently went through TSVWG last call, and will imminently be last called on various int-area lists, I believe. These are quite significant updates to outer fragment processing at the tunnel egress. But, given something has to be said, I can't think of a better way (see the original quoted email about why the logical OR of the ECN codepoints as defined in RFC3168 is no longer sufficient - and it's no simpler anyway). 5. ECN Propagation and Fragmentation/Reassembly The following requirements update RFC6040, which omitted handling of the ECN field during fragmentation or reassembly. These changes might alter how many ECN-marked packets are propagated by a tunnel that fragments packets, but this would not raise any backward compatibility issues: If a tunnel ingress fragments a packet, it MUST set the outer ECN field of all the fragments to the same value as it would have set if it had not fragmented the packet. As a tunnel egress reassembles sets of outer fragments [I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE markings on the basis that a congestion indication on a packet applies to all the octets in the packet. On average, a tunnel egress SHOULD approximately preserve the number of CE-marked and ECT(1)- marked octets arriving and leaving (counting the size of inner headers, but not encapsulating headers that are being stripped). This process proceeds irrespective of the addresses on the inner headers. Even if only enough incoming CE-marked octets have arrived for part of the departing packet, the next departing packet SHOULD be immediately CE-marked. This ensures that CE-markings are propagated immediately, rather than held back waiting for more incoming CE- marked octets. Once there are no outstanding CE-marked octets, if only enough incoming ECT(1)-marked octets have arrived for part of the departing packet, the next departing packet SHOULD be immediately marked ECT(1). For instance, an algorithm for marking departing packets could maintain a pair of counters, the first representing the balance of arriving CE-marked octets minus departing CE-marked octets and the second representing a similar balance of ECT(1)-marked octets. The algorithm: o adds the size of every CE-marked or ECT(1)-marked packet that arrives to the appropriate counter; o if the CE counter is positive, it CE-marks the next packet to depart and subtracts its size from the CE counter; o if the CE counter is negative but the ECT(1) counter is positive, it marks the next packet to depart as ECT(1) and subtracts its size from the ECT((1) counter; o (the previous two steps will often leave a negative remainder in the counters, which is deliberate); o if neither counter is positive, it marks the next packet to depart as ECT(0); o until all the fragments of a packet have arrived, it does not commit any updates to the counters so that, if reassembly fails and the partly reassembled packet has to be discarded, none of the discarded fragments will have updated any of the counters. During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if the ECN fields of the outer headers being reassembled into a single packet consist of a mixture of Not-ECT and other ECN codepoints, the packet MUST be discarded. A tunnel end-point that claims to support the present specification MUST NOT use an approach that results in a significantly different ECN-marking outcome to that defined by the "SHOULD" statements throughout this section. "SHOULD" is only used to allow similar perhaps more efficient approaches that result in approximately the same outcome. Bob On 16/05/2019 22:14, Bob Briscoe wrote: Joe, Sorry I missed this posting at the time (my mail filters moved both cross-postings into my int-area box which I check only rarely). On 27/04/2019 18:13, Joe Touch wrote: Cross-posting to let both communities know: - it would be useful for these documents to address how fragmentation and reassembly affects these signals (esp. if reassembling fragments with different ECN values) [BB] This is addressed by the re-framing section<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-12#section-4.6> in ecn-encap-guidelines, altho it doesn't give examples of what might have caused frame boundary misalignment, so fragmentation is not specifically mentioned. I think I will add an explicit mention of fragmentation (if only so a search finds that section). Actually I've realized that this highlights an inconsistency between the advice on ECN and fragment reassembly in RFC3168 and in ecn-encap-guidelines.: * RFC3168 requires that the ECN marking of a reassembled packet is the logical OR of the ECN marks on the fragments, * whereas ecn-encap-guidelines recommends marking the same number of outgoing as incoming octets when reassembling L2 frames or tunnelled packets with different boundaries - using a simple counter to track the balance. In fact, it was the review of RFC3168 by me and Jon Crowcroft back in 2001 that originally raised the question of how to handle reassembly of ECN-marked fragments<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-ip-00#section-11>. I'll quote a passage from the review, which I think justifies the recommendation in ecn-encap-guidelines to count marked bytes, rather than use the logical OR of RFC3168: To use the logical OR of the marking of all fragments might be a pragmatic solution, particularly for congestion control protocols like TCP where one loss per round trip is treated identically to many. However, it is becoming more common to see large numbers of packets per round trip time as data rates increase while packet sizes and the speed of light haven't increased for many years. Therefore it is to be expected that newer congestion control protocols might take more accurate account of the number of packets marked in a round trip. Hence, the inaccuracy of a logical OR during re-assembly at the IP layer is best avoided. I'm not too worried about the inaccuracy of using a logical OR, but I think it best to recommend more accurate and no less costly counting. The only justification for the logical OR was that TCP only reacted to one ECN mark per RTT. But that is changing now, and the behaviour of one transport should not be embedded in lower layers anyway. - it would be useful for these documents to consider draft-ietf-intarea-tunnels (which relates to the above) and its discussion on many of the protocols cited I can't find anything in draft-ietf-intarea-tunnels that ought to be cited from ecn-encap-guidelines or rfc6040-update-shim. Did you have something specific in mind? I do want to raise a question about the following sentence, which precedes the mention of ECN: There are exceptions to this rule that are explicitly intended to relay signals from inside the tunnel to the network outside the tunnel, typically relevant only when the tunnel network N and the outer network M use the same network. Was that last word meant to say "network protocol"? Then, if that is what you meant, I would disagree. Many different network protocols include concepts similar to Diffserv and/or ECN (e.g. IEEE802.1p, MPLS and TRILL support both, etc), and there's rarely a reason /not/ to propagate the concept between different network protocols when they encapsulate each other, even tho it's not always straightforward to do so. Bob Bob Joe On Apr 26, 2019, at 1:50 PM, Black, David <David.Black@dell.com<mailto:David.Black@dell.com>> wrote: This may be of interest to INT folks who are interested in tunnels and encapsulations. Comments by the WGLC deadline are encouraged, but comments after the deadline are ok, as they’d have to be dealt with anyway at IETF Last Call. Thanks, --David From: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> On Behalf Of Black, David Sent: Wednesday, April 17, 2019 2:51 PM To: tsvwg@ietf.org<mailto:tsvwg@ietf.org> Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019 [EXTERNAL EMAIL] This email announces a 2nd TSVWG Working Group Last Call (WGLC) on two drafts: [1] Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines-12 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ This draft is intended to become a Best Current Practice RFC [2] Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim draft-ietf-tsvwg-rfc6040update-shim-08 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ This draft is intended to become a Proposed Standard RFC. This WGLC will run through the end of the day on Monday, May 6, 2019. Comments should be sent to the tsvwg@ietf.org<mailto:tsvwg@ietf.org> list, although purely editorial comments may be sent directly to the author. Please cc: the WG chairs at tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org> if you would like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on either draft Thanks, David, Gorry and Wes (TSVWG Co-Chairs) _______________________________________________ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Joe Touch
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Bob Briscoe
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Bob Briscoe
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Black, David
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Joe Touch
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Jonathan Morton
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Markku Kojo
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Gorry Fairhurst
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Markku Kojo
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Bob Briscoe
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Bob Briscoe
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Jonathan Morton
- Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-enca… Black, David