Re: [6lo] Intdir last call review of draft-ietf-6lo-minimal-fragment-04

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 07 November 2019 22:36 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27B4120819; Thu, 7 Nov 2019 14:36:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=C4hHJu4H; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XVieFNLf
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 3TczNbn_fc6J; Thu, 7 Nov 2019 14:36:53 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349941200D7; Thu, 7 Nov 2019 14:36:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47917; q=dns/txt; s=iport; t=1573166213; x=1574375813; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yQfzKs9WJHDberClTCNPdd9Kxwhw2Ifake/+z0FdVMw=; b=C4hHJu4HzAj/WWD2kZvDKLmem52KBoJVtkoFCb2fTVBq6Bfp4A2tfq7J EmltV4OwvADs+G5ssAft3tBB4xEmFoR1q2a4AzRAKJVnd2cXbDsBv/nl3 51DSLvS0hVoUtL/QJPkB/ZGSfcZrPjhGSTuCXKHin2e5oLurZlBO3gsnx s=;
IronPort-PHdr: 9a23:x8inEx/2wSuqbP9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUERoMiMEYhQslVdaZCVDxIeT2Ryc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AWAAARm8Rd/5FdJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFsAwEBAQELAYEbLyQsBYFEIAQLKgqEH4NGA4sDgjkll36BLoEkA1QJAQEBDAEBLQIBAYRAAheDdyQ2Bw4CAwsBAQQBAQECAQUEbYU3DIVRAQEBAQIBEhEKEwEBNwEECwIBBgIOCiABCQICAjAlAgQOBSKDAIF6TQMOIAEClziQYwKBOIhgdYEygn4BAQWFCxiCFwmBNgGFGYQxgkkYgUA/gREnDBOBTn4+hDErgnkygiyNIIJnhT+JO48HCoIkjDmJCBuCPIdghDSLIqgwAgQCBAUCDgEBBYFZATGBWHAVGksBgkFQERSQNgkag1CKU3SBKI1TgTABgQ4BAQ
X-IronPort-AV: E=Sophos;i="5.68,279,1569283200"; d="scan'208,217";a="368029098"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2019 22:36:52 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xA7MaphP023671 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2019 22:36:51 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 16:36:51 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 17:36:49 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Nov 2019 16:36:49 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dcV57NJHUS951Vr8l+S4Z/zbNm4qSljIULkCHTcKG/upZTNuHEc2amNhzxISZcWzjT8wT0QiInrB439Z/+MAwvFoXXcaA6h0Ha3O33nyw3OY0q3zpBTJzI/7z0S1f74WoDphRgcLkl+/ISp8Ffng3vgZW+4uzkYnHhnUt4NSq6XnhJMPEDnkzABnygI+kYhWv5ywQqobwS1T+SgrVz8iqME6apEzWRApkRtXVSMkkl/ADJ/LvwWqBJxQUtutL4CuOwmbe+ZKrg99u4rLe13qF94lIj/TMFQe/nUNywht1LmfpCxpt5z5mz//1/y+a3nHJMf0+uCwY+g5AviXcSd2UQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yQfzKs9WJHDberClTCNPdd9Kxwhw2Ifake/+z0FdVMw=; b=L7leL6tKnw+v3gjPlorvQqCjmS4HiZjiAts82ECEucyoUTzqeWA5hLWMqMs2fBaHA2gLmisUURnQSaWDZLch/EVwx+CECqc7OiyHeA8PSUAK0cKB1gdI6jD+1cCE8HHAWmnm1jmN2bOMbJCPyqAIgduFlnnq2VzP8bETcmqiTyPsQyQuyHmqBzGh0Ms3OGcmRM2K1z+ODhNxflEWHJ65NC8ewdIeQMjSxJfVHS1vCX7v9Ri+itEjXVNr4s343AMLy+JHiyKPxxBcL7wM4xEhPjbf7yOcn78OK/bjx78TiX3XPCK4WGpnVyWzqackCMXGSt5qkaDZSw8VJE5WRleckQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yQfzKs9WJHDberClTCNPdd9Kxwhw2Ifake/+z0FdVMw=; b=XVieFNLfwidfG10F72mS/TdmmaO1roPu1GVfFzIpjMWTV5Na6dpMDj0zzFi9ds1NuTUtdpQAqw7aeITxoa4qaGykDwHueinl/3Zgb48LFRJJJ69bXPxkDUcBDxAfxatYk8Uo3kX6vniP+MDP7O0JaLc6ZlK+DzLGHpX5/Vext3o=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3806.namprd11.prod.outlook.com (20.178.254.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.22; Thu, 7 Nov 2019 22:36:48 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2430.020; Thu, 7 Nov 2019 22:36:48 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Dave Thaler <dthaler@microsoft.com>
CC: "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-6lo-minimal-fragment.all@ietf.org" <draft-ietf-6lo-minimal-fragment.all@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
Thread-Index: AQHVlPdRdAzM57x8DkqeVzdB76HcJ6d/f0lAgAC5jgCAABTpfg==
Date: Thu, 07 Nov 2019 22:36:48 +0000
Message-ID: <426C0687-C855-4948-AB27-DD824B990294@cisco.com>
References: <157308179603.20089.3680167711838185681@ietfa.amsl.com> <MN2PR11MB356517192D428E8181F7FB06D8780@MN2PR11MB3565.namprd11.prod.outlook.com>, <MWHPR21MB0784B933306ADFFE22E0B2E5A3780@MWHPR21MB0784.namprd21.prod.outlook.com>
In-Reply-To: <MWHPR21MB0784B933306ADFFE22E0B2E5A3780@MWHPR21MB0784.namprd21.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [146.0.25.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0957cbe5-54ee-425e-8b7c-08d763d2fa12
x-ms-traffictypediagnostic: MN2PR11MB3806:
x-microsoft-antispam-prvs: <MN2PR11MB3806B3996749D3BFE673BA5BD8780@MN2PR11MB3806.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(396003)(136003)(376002)(43544003)(55674003)(199004)(189003)(6506007)(102836004)(66446008)(66946007)(91956017)(5660300002)(561944003)(66476007)(66556008)(64756008)(81156014)(6486002)(86362001)(76176011)(71200400001)(486006)(6436002)(33656002)(76116006)(6512007)(11346002)(476003)(2616005)(8676002)(446003)(6246003)(71190400001)(66574012)(14454004)(186003)(1511001)(8936002)(7736002)(4326008)(26005)(54896002)(790700001)(6116002)(3846002)(478600001)(36756003)(81166006)(229853002)(45080400002)(99286004)(2906002)(14444005)(54906003)(316002)(256004)(66066001)(25786009)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3806; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gV3QNV83gbYTnRaNCLnLBGedluvRYDQRxH2R/kvLNh7aZr9UMKaInneYRhBoHM8N6ObQ1mVzpCjVFs5cHka+rpfve/g1sW7fe3/jl4jMhMwRkwBTo2PQZleb1BtlrGRleU9OF/ogTAXQ3rYy/ur+EntpD7UFuh6V2Q8ZrCicWoOH1nyzHJmg5ndiKFnFAyLv+5Aj9qSA5biymRaETsBmYoY/L4u7Ekjlc+u2cGz0bPl0pTdXOF9itnl02Vf9mGVgruOm6IYUcAMx/Zy535u0ntSD+2CqWtLuYLCJv/HHUAmuEF5Ey25hpBopkVwgiAgzYkKoJeOKsBgFjyNDGa446efImU44CKfPRAB8o5M7a1hiR2TZHOb+5zwRMBALdcvOTUCVAzQcO4LBcrGjMHZXgbk4SxP8kj7IWHTUiXTMVcitdwT2dUfB9BXF4PB7gi76
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_426C0687C8554948AB27DD824B990294ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0957cbe5-54ee-425e-8b7c-08d763d2fa12
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 22:36:48.5336 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9mkYaeSDviUa4BCfTigXCMFekpVj3bvI3twZs92XHUkEUoYV10smwJkt2UBWp/smB8ud3N7wkIUHdeaOtiRI0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3806
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/rNkIcm-LTp8Qkgif8hGX9Y8xZMg>
Subject: Re: [6lo] Intdir last call review of draft-ietf-6lo-minimal-fragment-04
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 22:36:57 -0000

Hello Dave

Please see in-line

Le 7 nov. 2019 à 22:22, Dave Thaler <dthaler@microsoft.com> a écrit :



Responses inline below.

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> The title implies the document specifies a forwarding mechanism, but

> it does not, it merely provides discussion of two mechanisms in other

> docs (RFC 4944 and draft-ietf-lwig-6lowpan-virtual-reassembly). I

> would recommend at least changing the title to be more clear as to the purpose of the doc.



A suggestion would help : )



Does "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" go the right way?



Sure.  Other possibilities in case you like them better than that one:

·        “6LoWPAN Fragment Forwarding Techniques: Discussion and Tradeoffs”

·        “An Analysis of Various 6LoWPAN Fragment Forwarding Mechanisms”

Etc.


We (== this draft) do not compare technologies. We give a generic behavior for which the LWIG draft is an implementation. So it’s not a protocol per se but a way do use RFC 4944 that was not intended in 4944.




> Technical confusion

> -------------------

> 1) Page 3 says the reassembly buffer contains "the link-layer address

> that node B uses to forward the

>    fragments".  I cannot tell whether this is referring to B's link-layer

>    address that it received the fragment on, or B's link-layer address that it

>    uses as a source link-layer address for forwarding it on, or the link-layer

>    address of the next hop to which B forwards.



The latter. B needs to send all the fragments with the same source link-layer address because that's part of the index for the datagram in C. Proposed change:

"

the Link-Layer address that node B uses as source to forward the fragments



"



Ok



> 2) Page 3 also says the reassembly buffer contains "the link-layer

> address of the next hop that is resolved

>    on the first fragment".  I found this similarly confusing.  What does it

>    mean to resolve something "on" the first fragment?  Does it mean "during

>    processing of the first fragment"?  Maybe I missed it, but I couldn't find

>    in RFC 4944 anywhere that says that it would do next-hop resolution before

>    the datagram can be reassembled.  That would seem like a waste, if the

>    fragments are then discarded (e.g., due to timer expiry) without actually

>    doing any forwarding.

>



RFC 4944 reassembles and then routes. We make the routing decision on the first fragment before we receive the second fragment, forward the first fragment and store that state. Unsure how to reword, your suggestion would be appreciated.



When you say “We made”, who is “we”?  RFC 4944?  If so, cite a specific section,
since making the routing decision on receipt of the first fragment, rather than the last,
seems non-intuitive and wasteful.   If that’s what the RFC says, then you can point it out

since this doc is (from my understanding) about discussing issues and tradeoffs with other mechanisms.

We is this draft. The art of 4944 reassembles the packet at each hop. Once the packet is reassembled then it is routed leading to the behavior you describe, that is resolve on last fragment.

This draft forwards a fragment as soon as it is received leading to more streamlined operations, less buffer bloat and lower latency. It is indeed wasteful if some fragments are missing after the first one since the first fragment will still continue till the end. That’s the other side of the coin, similar to store and forward switching vs. switching as the frame is being received.





The waste is that if you choose to discard the datagram rather than forward it,
your efforts in doing the lookup are a waste of cycles, and a waste of space to store the result.

This is pleading for reassembly at each hop. All the benefits of forwarding fragments are gone.


If you have a constrained node where every byte of storage is precious, having to store another

link-layer address can be burdensome, as opposed to a mechanism that only does the lookup

post reassembly, and has no such storage requirements, thus is lighter weight and arguably
better for constrained nodes.



But must store 1K for each message and for a long time on slow links as opposed to 80 bytes at a time.




I would encourage adding such discussion into this doc.



Sure! Your remarks enlighten a lack of discussion on pro cons that can be useful to decide whether to turn on the method. There are other aspects like hidden terminal between fragments where hop 2 sending to hop 3 may interfere at hip 1 with reception of next fragment from hop 1.




> 5) Section 3 explains that "the first fragment must always be

> forwarded first", but does not explain

>    what the behavior is if a fragment other than the first fragment is received

>    before the first fragment. Figure 1 shows that the fragments can be received

>    out of order, since there fragment 6 is received before 5, which is received

>    before 4.   Presumably it is either queued or dropped.  If it's queued, then

>    section 4 is insufficient, which talks about an attacker generating a large

>    number of bogus "fragment 1" fragments, since if you queue the first

>    fragment received even if it's not "fragment 1", then the same attack

>    presumably exists, it's not specific to "fragment 1" packets.

>



6LoWPAN does not mandate that all the fragments are sent in order, thus Fig1. But fragment 1 is sent first Quoting section 5.5 of Rfc 4944 "

                                                                   The first link fragment

   SHALL contain the first fragment header as defined below.



                           1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |1 1 0 0 0|    datagram_size    |         datagram_tag          |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                         Figure 4: First Fragment



   The second and subsequent link fragments (up to and including the

   last) SHALL contain a fragmentation header that conforms to the

   format shown below.



                           1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |1 1 1 0 0|    datagram_size    |         datagram_tag          |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |datagram_offset|

      +-+-+-+-+-+-+-+-+



                      Figure 5: Subsequent Fragments "



The first fragment is the one with the IPv6 address of the destination that enables to find the next hop that the other fragments will use. So it is always available before a fragment can be forwarded. So it is easy to mandate that we forward it first.



The text we’re discussing is about the order of receipt, not the order in which they are sent.

Even if it’s forwarded first, it does not mean it was received first (e.g., whether due to packet loss
or whatever other reason).



If we do that then the only way for a next fragment to arrive first is that the first fragment was lost in the transmission by the previous node. The first fragment may be queued for retries in the previous hop but that's a really bad idea.



Regarding “that’s a really bad idea”… if this draft is the one discussing tradeoffs and variations, then perhaps
it should explain why “that’s a really bad idea”.



Proposal:



* we add text on the above to clarify

* we mandate that on a link with ARQ, the node only forwards a next fragment if the first was acknowledged.

* we clarify that a next fragment that is received with no state from a first fragment for that datagram should be dropped.



If by “clarify”, you mean by reference to normative text in the RFC that specifies it, then ok.



Cool will work on that too


[…]

> Abstract has "to the virtual Reassembly Buffer", which seems incorrect

> both in terms of capitalization (since sectoin 3 has VRB) and grammar.

> Suggest "to using virtual reassembly buffers".



I think we meant to the VRB draft. Applied your recommendation in the meantime:

"

This method reduces the latency and increases end-to-end reliability in route-over forwarding.

It is the companion to using virtual reassembly buffers which is a pure implementation technique.



"

Does that read well?



Ok.



Dave

Many thanks Dave,

I’m traveling most time between now and IETF, will still try to propose text and submit to your approval with best delay.

Take care

Pascal