[tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

"Black, David" <David.Black@dell.com> Sun, 15 September 2019 21:09 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A4CBC12020A for <tsvwg@ietfa.amsl.com>; Sun, 15 Sep 2019 14:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.179
X-Spam-Status: No, score=-0.179 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=2.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=LZhyeyTZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=mhgVC5TE
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TSjBtn8Q7xKk for <tsvwg@ietfa.amsl.com>; Sun, 15 Sep 2019 14:09:37 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com []) (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 646BD1200B3 for <tsvwg@ietf.org>; Sun, 15 Sep 2019 14:09:37 -0700 (PDT)
Received: from pps.filterd (m0170394.ppops.net []) by mx0b-00154904.pphosted.com ( with SMTP id x8FL4sM3023613 for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:09:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=1ksN9VYS5EApwTjf07RtCLQgXM1wL3KBma09DMZr5xE=; b=LZhyeyTZCZXlEP5pvgn7tIZgvqDWhb3R2vnar1HwdzuSCFhKyOZwaZO4Am51Dh2Rv7er w970DNl6Slc8yhRGim9QvVhZo1+brjoG/HJ5c4BxiWw/opq2SIGxtL2vv1+CAhKxJY0o xEvvZ7QJNLrfbLoTL9lZWejj4lkiCpXX59gfE+pIoFeETXmJvvDkLH0wCXt5HWcXhH56 tZA01/w/LL/wVaxHkTlCKzZkK+/oF8ZFzK2EmxdH8TZ4Q8lbwrdumgOKRiOwUsF6yNFY XtVR22MFX/MNRZhJtg95awwYa1UO3vNfi072eWYZUxqOdJU/spd4zW9TmTELtZIw9754 sg==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com []) by mx0b-00154904.pphosted.com with ESMTP id 2v0ts5vr0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:09:35 -0400
Received: from pps.filterd (m0144103.ppops.net []) by mx0b-00154901.pphosted.com ( with SMTP id x8FL87e8143935 for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:09:34 -0400
Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2v0trdfa8y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:09:34 -0400
Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com []) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8FL9LSR024879 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:09:34 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x8FL9LSR024879
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1568581774; bh=IUA5YQ6MEOVp7ndPcVx6cOacqAo=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=mhgVC5TErA2Q3CJbCZ5Y1rcamauSgLOaOTKpwo2JU1zcNlzZsbxyrvVMDPtGFDSD+ CNAU5CKCagCrRQ55AWgtUiTGgbi1nPmEzRXriIcWQtYoX8toWsxIMgogVHMf2GMiTQ Qq8y0P8ZfO80jakEyiEMsAWEpnsdpmV10SHBHUEM=
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com []) by maildlpprd53.lss.emc.com (RSA Interceptor) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:07:10 -0400
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com []) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8FL7DHM030133 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 17:07:13 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([]) with mapi id 14.03.0439.000; Sun, 15 Sep 2019 17:07:13 -0400
From: "Black, David" <David.Black@dell.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Status of ECN encapsulation drafts (i.e., stuck)
Thread-Index: AdVsCYkZeuBcfem2QOGSdU1A50z0Sw==
Date: Sun, 15 Sep 2019 21:07:11 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
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-09-15T20:54:35.4416142Z; 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: []
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936306F8925MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-15_11:2019-09-11,2019-09-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxscore=0 phishscore=0 spamscore=0 bulkscore=0 priorityscore=1501 adultscore=0 suspectscore=0 malwarescore=0 clxscore=1015 mlxlogscore=958 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909150232
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 phishscore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 impostorscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909150231
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hfnrRZXkFDyfoceqy9kyK1iNazo>
Subject: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
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: Sun, 15 Sep 2019 21:09:40 -0000

This email concerns draft-ietf-tsvwg-ecn-encap-guidelines and draft-ietf-tsvwg-rfc6040update-shim, which are being handled together for WG Last Call and RFC publication, and is posted in my role as shepherd and responsible WG chair for these drafts.

The current situation is that both drafts are stuck due to a problem with the fragementation text added to the rfc6040update-shim draft.   Section 5 on ECN Propagation and Fragmentation/Reassembly was added to that draft in response to a WGLC comment, and it appears to have gone too far in the direction of trying to do the proverbial "right thing".

The core of the problem is in these two paragraphs in Section 5 of that draft (https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#section-5):

   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


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

Much as that may be the proverbial "right thing" to do, particularly with the benefit of 20/20 hindsight, that text is inconsistent with the following text from Section 5.3 of RFC 3168 (https://tools.ietf.org/html/rfc3168#section-5.3), as Markku Kojo has pointed out:

   ECN-capable packets MAY have the DF (Don't Fragment) bit set.

   Reassembly of a fragmented packet MUST NOT lose indications of

   congestion.  In other words, if any fragment of an IP packet to be

   reassembled has the CE codepoint set, then one of two actions MUST be


      * Set the CE codepoint on the reassembled packet.  However, this

        MUST NOT occur if any of the other fragments contributing to

        this reassembly carries the Not-ECT codepoint.

      * The packet is dropped, instead of being reassembled, for any

        other reason.

   If both actions are applicable, either MAY be chosen.  Reassembly of

   a fragmented packet MUST NOT change the ECN codepoint when all of the

   fragments carry the same codepoint.

The 6040update-shim draft is intended to update RFC 6040, and a number of the tunnel protocol drafts, but it is not intended to update RFC 3168, and hence the above new text (albeit well-intentioned) is a showstopper.   Changing ECN fragmentation behavior should be done in a separate draft.

Bob (as draft editor) - do you want to propose some new text to the list, possibly after private email discussion with Marco and me to figure out what it needs to say?

Thanks, --David
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754