Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text

"Black, David" <David.Black@dell.com> Wed, 09 October 2019 13:34 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 269B0120105 for <tsvwg@ietfa.amsl.com>; Wed, 9 Oct 2019 06:34:50 -0700 (PDT)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=xxddlJC2; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=kghIBv6A
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 QZcouDBPLUTO for <tsvwg@ietfa.amsl.com>; Wed, 9 Oct 2019 06:34:48 -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 60DD21200F7 for <tsvwg@ietf.org>; Wed, 9 Oct 2019 06:34:48 -0700 (PDT)
Received: from pps.filterd (m0170391.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x99DVsgL021782; Wed, 9 Oct 2019 09:34: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 : content-transfer-encoding : mime-version; s=smtpout1; bh=Fk89UBgIQAFNbJx9IOqvczZojL04FBSmCwkPg22gsLA=; b=xxddlJC2BqwIovTXEO3ykcjE/wUzc6QsKEzJc6aTbvnOI754i2lhCwzDEuMUnCYXm8k/ nmjUFuBcCZc+Ouo7efpbst0866UZ3A8PNqBJfB54CDW4SLYfz5B0DNuuokB9Kq4/Pou0 InYBL+bzHirxf9KxQPo4FUFXSwmMUC22t2QfN4nmD60gRGnbfw/soeS2/u898EMedncX PnYM+ljDAg3/tbygSSTNAVTJ9vBpZtoVkRBxy6LEvlXh7A8dzjS3ldop+jyTRJ/RFpGv p2GUg0Nc4zNZIjxjfCX/yP06bcP6ZFRKf3L4iNUn4QHRVsw5DlH75iYmf1Q6VFtRiXzm /Q==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2vepaybf2n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 09:34:45 -0400
Received: from pps.filterd (m0133268.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x99DXCul047244; Wed, 9 Oct 2019 09:34:41 -0400
Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [128.221.224.79] (may be forged)) by mx0a-00154901.pphosted.com with ESMTP id 2vf88kugax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 09 Oct 2019 09:34:41 -0400
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x99DYUQe005062 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Oct 2019 09:34:39 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com x99DYUQe005062
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1570628079; bh=C23mFYyg8+X4bntEJNFDWS/CwFo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kghIBv6ADobXGEqU2mMt4C16iHCczcdb0/wd3WNSPuCdfmOMn/8CtWbSCrFNfWTQk fF+Kb58cjs+z8cd9+lMQ7MelU3wOiURGfCeEIdCYTez84cw9bZLfhWsrerj6UtykzV iXA+A5X/ZUVXxnUengLXF3Wzsmqqne2jCRFYLh5M=
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 9 Oct 2019 09:33:41 -0400
Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x99DXlGR024190 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 9 Oct 2019 09:33:52 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0439.000; Wed, 9 Oct 2019 09:33:51 -0400
From: "Black, David" <David.Black@dell.com>
To: Jonathan Morton <chromatix99@gmail.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text
Thread-Index: AQHVfitzwkTirbnA0keACWY5ofodXKdST6Ug
Date: Wed, 9 Oct 2019 13:33:50 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630768173@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com> <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.com>
In-Reply-To: <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.com>
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-10-09T13:33:49.8786907Z; 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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-09_06:2019-10-08,2019-10-09 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 phishscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090130
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 malwarescore=0 phishscore=0 impostorscore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090129
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/D8zeB7S73dXv6LbajCcGa3hXPxM>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text
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, 09 Oct 2019 13:34:50 -0000

> The one case this doesn't really cover is what happens when a fragment set
> has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very
> relevant to current ECN usage, but may become relevant with SCE, in which
> middleboxes on the tunnel path may introduce such a mixture to formerly
> "pure" packets.  From my perspective, a likely RFC-3168 compliant
> implementation of arbitrarily choosing one fragment's ECN codepoint as
> authoritative (where it doesn't conflict with other rules) is acceptable, but
> this doesn't currently seem to be mandatory.
> 
> With the above language, it should be sufficient to update RFC-3168 to cover
> this case at an appropriate time, rather than scattering further requirements
> in many documents.

I would concur that using a separate draft to cover that case at the appropriate time would be the better course of action.

Thanks, --David

> -----Original Message-----
> From: Jonathan Morton <chromatix99@gmail.com>
> Sent: Tuesday, October 8, 2019 6:55 PM
> To: Black, David
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
> Fragmentation/Reassembly text
> 
> 
> [EXTERNAL EMAIL]
> 
> > On 8 Oct, 2019, at 10:51 pm, Black, David <David.Black@dell.com> wrote:
> >
> > **NEW**: Beyond those first two paragraphs, I suggest deleting the rest
> of Section 5 of the rfc6040update-shim draft and substituting the following
> paragraph:
> >
> >    As a tunnel egress reassembles sets of outer fragments
> >    [I-D.ietf-intarea-tunnels] into packets, it MUST comply with
> >    the reassembly requirements in Section 5.3 of  RFC 3168 in
> >    order to ensure that indications of congestion are not lost.
> >
> > It is certainly possible to continue from that text to paraphrase part or all of
> Section 5.3 of RFC 3168, but I think the above text crisply addresses the
> problem, and avoids possibilities of subtle divergence.  I do like the
> “reassembles sets of outer fragments” lead-in text (which I copied from the
> current rfc6040shim-update draft) because that text makes it clear that
> reassembly logically precedes decapsulation at the tunnel egress.
> >
> > Comments?
> 
> Looks good to me.
> 
> The one case this doesn't really cover is what happens when a fragment set
> has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very
> relevant to current ECN usage, but may become relevant with SCE, in which
> middleboxes on the tunnel path may introduce such a mixture to formerly
> "pure" packets.  From my perspective, a likely RFC-3168 compliant
> implementation of arbitrarily choosing one fragment's ECN codepoint as
> authoritative (where it doesn't conflict with other rules) is acceptable, but
> this doesn't currently seem to be mandatory.
> 
> With the above language, it should be sufficient to update RFC-3168 to cover
> this case at an appropriate time, rather than scattering further requirements
> in many documents.
> 
>  - Jonathan Morton