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

"Black, David" <David.Black@dell.com> Wed, 09 October 2019 15:03 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 8216F1200F6 for <tsvwg@ietfa.amsl.com>; Wed, 9 Oct 2019 08:03:45 -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=fdshEqBf; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=RmQDk87o
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 uoN0uHAH-XE5 for <tsvwg@ietfa.amsl.com>; Wed, 9 Oct 2019 08:03:43 -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 459021200E7 for <tsvwg@ietf.org>; Wed, 9 Oct 2019 08:03:43 -0700 (PDT)
Received: from pps.filterd (m0170392.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x99EsxSl030756; Wed, 9 Oct 2019 11:03:42 -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=kJAmiO26waIFSbTjdvEoOaCYOE8OEt6A0XQpYM7qRQQ=; b=fdshEqBfJOgQmXPHrn+VoQMz0B5p7nNgfLsbwcM3M6bBfGY/dA52Hr/q1TmjFqOmsHmd U6HQcQtsJEYXNT4Z7rlj07ySlg3FMu6CQoms8+LKCBgiwuQhPKVo1va4PB9Qbzl30ngX OWDdeThIlxULHkcEAJv6tXQOQbO/ve60Sk0th9he+lQmlMIzq+Ssz9QsmjZ3hTvc/vyr Nost0BpBd8dQpXS7EpklsKNl14mHIGvjL5RF708LKGe+TV7eX7HIfxD/2RBQRqHPwoxj ksP9+BwgrSDOa0c4ZSwqDe03xm8MA84cIdlnfHQ+Jl19P9DV9+ZNAhekNrePm5UyKLrF bg==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2vepbfbtf5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 11:03:42 -0400
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x99Evhnl065394; Wed, 9 Oct 2019 11:03:41 -0400
Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [128.221.224.79] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2vh0nf70fp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 09 Oct 2019 11:03:40 -0400
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x99F1wqJ025602 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Oct 2019 11:03:29 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com x99F1wqJ025602
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1570633410; bh=ISkzoqWQpyJsgHWQ001iPJiBVHY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RmQDk87oJRpF8BzjcSoJeBAIInYdw/iW/Yfr0fN3z5xvAPCow7Gbmybb3iEI0KC7B PgCnVgoxp9yfnexbOknAP6MlplXN7nN9MT1HDgVKgtz4dYC9oRSpgAmPn4t79+ZTxE WSuJmNYIW1JbpLzwLgd4NdYAXCRGsDpBxutle5zA=
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 9 Oct 2019 10:59:41 -0400
Received: from MXHUB304.corp.emc.com (MXHUB304.corp.emc.com [10.146.3.30]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x99ExgAG027373 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 9 Oct 2019 10:59:42 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB304.corp.emc.com ([10.146.3.30]) with mapi id 14.03.0439.000; Wed, 9 Oct 2019 10:59:41 -0400
From: "Black, David" <David.Black@dell.com>
To: Joe Touch <touch@strayalpha.com>
CC: Jonathan Morton <chromatix99@gmail.com>, "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: AQHVfitzwkTirbnA0keACWY5ofodXKdST6UggABS6oD//8QfMA==
Date: Wed, 9 Oct 2019 14:59:41 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936307688C5@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com> <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.com> <CE03DB3D7B45C245BCA0D2432779493630768173@MX307CL04.corp.emc.com> <6D176D4A-C0A7-41BA-807A-5478D28A0301@strayalpha.com>
In-Reply-To: <6D176D4A-C0A7-41BA-807A-5478D28A0301@strayalpha.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-09T14:57:50.5689394Z; 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: mailusrhubprd02.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 mlxlogscore=999 malwarescore=0 bulkscore=0 spamscore=0 suspectscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090142
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 spamscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090142
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UQL_3BW-7_Qjcp4xKv1Y6nPjeiI>
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 15:03:46 -0000

At this juncture, for an ECT(0)/ECT(1) mix across a set of fragments being reassembled, I would suggest using "any" (i.e., either is ok) at this juncture to avoid constraining what we may do in the future; in particular, this allows use of the value in the first or last fragment, both of which are likely to be convenient approaches for some implementations.

Thanks, --David

> -----Original Message-----
> From: Joe Touch <touch@strayalpha.com>
> Sent: Wednesday, October 9, 2019 10:29 AM
> To: Black, David
> Cc: Jonathan Morton; tsvwg@ietf.org
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
> Fragmentation/Reassembly text
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi, all,
> 
> I disagree with the suggestion below.
> 
> Pushing this “under the rug” for an indeterminate later date only serves to
> undermine the importance of this issue.
> 
> At a MINIMUM, there needs to be direct guidance in place until a “better”
> solution can be developed. For now, that would mean one of the following:
> - use the max of the frag code point values
> - use the min of the frag code point values
> - use “any” of the frag code point values
> - pick some other way (first, the one in the initial fragment i.e., offset 0), etc.
> 
> One of these needs to be *included at this time*.
> 
> If a clean up doc needs to be issued, it can override individual “scattered”
> recommendations later.
> 
> Joe
> 
> > On Oct 9, 2019, at 6:33 AM, Black, David <David.Black@dell.com> wrote:
> >
> >> 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
> >