Re: [6lo] review of draft-ietf-6lo-fragment-recovery-02

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 20 May 2019 09:46 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 A0A5F12014F for <6lo@ietfa.amsl.com>; Mon, 20 May 2019 02:46:40 -0700 (PDT)
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=cAnv6Nwc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OMh8QlGS
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 M08odc5WMlfX for <6lo@ietfa.amsl.com>; Mon, 20 May 2019 02:46:35 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1C712012B for <6lo@ietf.org>; Mon, 20 May 2019 02:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95800; q=dns/txt; s=iport; t=1558345594; x=1559555194; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ttGyvOI3N9R5u7TgO2qE/+MtSDhJuk11Fc+X5z0Hhqw=; b=cAnv6NwczZg42NjxD+TEgRlBV2NqERi0Bj/R6KY6QgPcF4GEpLqcaJu+ jV12Og67hh3btLbrCI5aBm7wUIgu+rU8GPNvyu6fh85Hi1web2riuTG7h MJj3sK1WpPhyhQvS941IHzjmszC4Drczxr90tHJ9OYREYHUl9zhDgqh/x s=;
X-Files: image001.gif : 877
IronPort-PHdr: =?us-ascii?q?9a23=3AFe5BVhaxJ36SN9/BHrcaOqT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQCPduJc/4ENJK1bAgIGHAEBAQQ?= =?us-ascii?q?BAQcEAQGBUwUBAQsBgQ4vJAUnA2lNCCAECyiEE4NHA453g1WWKYEuFIEQA1Q?= =?us-ascii?q?CBwEBAQkBAgEBIwoCAQGEQAIXgiEjNgcOAQMBAQQBAQIBBG0cDIVLAgQFDQg?= =?us-ascii?q?JAggBEgEBIgMTDwIBCB0BAQEYAQkCAgIFEAEFCQwlAgQBCQgBBgIBBRSCSje?= =?us-ascii?q?BagMdAQIMmg0CgTWIX3GBL4J5AQEFhH0YgggHCYE0AYRmhmoXgUA/gRFGgU5?= =?us-ascii?q?JNT6CYQOBLAkGDQoQFYJzMoImiwsFJIJChF18gRqGBIZRAYU8Ql8JAoINhSs?= =?us-ascii?q?BhUOIKIIdhlWDeoVSg2GLN4EblTsCBAIEBQIOAQEFgVUBMYFXcBWDJwmCBgk?= =?us-ascii?q?DF4EBAQKCSIUUhT9yAYEoiy8Egk4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,491,1549929600"; d="gif'147?scan'147,208,217,147";a="273908253"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 May 2019 09:46:30 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x4K9kU8W024723 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2019 09:46:30 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 20 May 2019 04:46:29 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 20 May 2019 04:46:28 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 20 May 2019 05:46:27 -0400
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=ySlRDhLm2GuKAP0zqzxfj4Sr9bO9pW4udr5MTaUMv2w=; b=OMh8QlGSrwi2fwrpJygQBCfOuT+9BT//r/x/doJ/1+chvSJj0UgQ4TvIghywKNE72+3Jm7xXYXtxxNaG3AX3h6dQI3s2yXxFC6WEaCiQzaTanZCK9EYKhQmR5sLOhVHvJX4nfxmQ2G6OM8iH/HF1X1gJbCw+DpBZXMM9G1ipD/M=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3949.namprd11.prod.outlook.com (10.255.181.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Mon, 20 May 2019 09:46:26 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1900.020; Mon, 20 May 2019 09:46:26 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Laurent Toutain <laurent.toutain@imt-atlantique.fr>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] review of draft-ietf-6lo-fragment-recovery-02
Thread-Index: AQHVBwMdy8sapwWQkUaSZ8iPlV+W0qZtv2dg
Date: Mon, 20 May 2019 09:46:16 +0000
Deferred-Delivery: Mon, 20 May 2019 09:45:53 +0000
Message-ID: <MN2PR11MB3565DB4C9D9E40F0CF3F6F8FD8060@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CABONVQao0ey_fkimA4P3rDsOaEaL2HHMDcYUbgHdQ03yXBOEZw@mail.gmail.com>
In-Reply-To: <CABONVQao0ey_fkimA4P3rDsOaEaL2HHMDcYUbgHdQ03yXBOEZw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1005::182]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6efdeba2-c667-4c09-ab79-08d6dd0806c5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:MN2PR11MB3949;
x-ms-traffictypediagnostic: MN2PR11MB3949:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <MN2PR11MB39495DB9F9C9067670F31B1ED8060@MN2PR11MB3949.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 004395A01C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(39860400002)(346002)(396003)(43544003)(199004)(189003)(8676002)(71200400001)(71190400001)(2501003)(8936002)(81156014)(81166006)(52536014)(6666004)(478600001)(14454004)(66946007)(66616009)(66476007)(66556008)(64756008)(66446008)(73956011)(76116006)(7736002)(76176011)(25786009)(606006)(102836004)(316002)(68736007)(6506007)(186003)(7696005)(66574012)(229853002)(733005)(99936001)(30864003)(74316002)(6436002)(256004)(14444005)(6246003)(46003)(86362001)(6116002)(53936002)(110136005)(33656002)(790700001)(99286004)(5660300002)(11346002)(55016002)(54556002)(9686003)(6306002)(54896002)(236005)(476003)(486006)(446003)(2906002)(53946003)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3949; 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-message-info: unb/qZds+pk7Xe+WFWTD00R2dRenNvTYEy7z50vRHHmdUpWFx5pfh72YKcGJEhesAQyWTyhcnAEd8iZ7UjRCGxdxYtV/oZRxhIbNUVNl+P+FWobZDmyAguvx5s5F6PH799UUszhll7b7k/CkFsxXtnlvjxbGd5uIFtZiM1LgIhk0UIWDRvHYBn95j+0Bhim7TvPB3biYKAAubGH4XZJ+FYIJpPWR0DCJ82e/pdCLM94Wk+CRnRaltDsG6Rf5JHxwUxs+HaaeV2+y4eeBgj9/WIM7sP2vlFYb4lKCCs8uV9Tm0u2WozCDzGiSWzuQ2kFsNeLttY9Iqy0RFkw6FXrxEHOxDiseTns79il5hZc0VSEwVYsnH8DVSbj+uOkjNbpf5wo5qSPV17OGcFKc5F+C6bpbQhg+73cqXhzVQ2dH4dA=
Content-Type: multipart/related; boundary="_004_MN2PR11MB3565DB4C9D9E40F0CF3F6F8FD8060MN2PR11MB3565namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6efdeba2-c667-4c09-ab79-08d6dd0806c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2019 09:46:26.0059 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3949
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/s-qMZ_CYUGXpRZT0EDx9EZSq-v0>
Subject: Re: [6lo] review of draft-ietf-6lo-fragment-recovery-02
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: Mon, 20 May 2019 09:46:41 -0000

Hello Laurent

Many thanks for your review : )

Let’s see below


   a new protocol.  However, adding that capability alone to the local
   implementation of the original 6LoWPAN fragmentation would not
   address the

bulk of the issues raised against it, and may create new
   issues like remnant state in the network.

LT: can you specify or give some references.
PT> well there are papers such as Georgios’, but it is unusual to add such reference in an RFC.
Still I agree as such it is open ended. What about:

        However, adding that capability alone to the local implementation of the
        original 6LoWPAN fragmentation would not address the issues of resources
        locked and wasted transmissions due to the loss of a fragment.
        <xref target="RFC4944"/> does not define a mechanism to first discover a
        fragment loss, and then to recover that loss. With RFC 4944, the
        forwarding of a whole datagram fails when one fragment is not delivered
        properly to the destination 6LoWPAN endpoint. Constrained memory
        resources are blocked on the receiver until the receiver times out.
        That problem is exacerbated when forwarding fragments over multiple hops
        since a loss at an intermediate hop will not be discovered by either the
        source or the destination, and the source will keep on sending fragments,
        wasting even more resources in the network and possibly contributing to
        the condition that caused the loss to no avail since the datagram cannot
        arrive in its entirety.



   (to be confirmed by IANA) The new 6LoWPAN Dispatch types use the
   Value Bit Pattern of 11 1010xx from page 0 [RFC8025], as follows:

              Pattern    Header Type
            +------------+------------------------------------------+
            | 11  101000 | RFRAG       - Recoverable Fragment       |
            | 11  101001 | RFRAG-ARQ   - RFRAG with Ack Request     |
            | 11  101010 | RFRAG-ACK   - RFRAG Acknowledgment       |
            | 11  101011 | RFRAG-ECHO  - RFRAG Ack with ECN Echo    |
            +------------+------------------------------------------+


LT: This space is marked experimental use by IANA. Why not select a value in another page (rfc 8025).
PT> Hum… no.  The experimental is only for page 15. It is free in all pages including 0. Sorry the table is a bit confusing to read due to that other dimension (pages).

Bit Pattern [https://www.iana.org/assignments/_support/sort_none.gif]
Page [https://www.iana.org/assignments/_support/sort_none.gif]
Header Type [https://www.iana.org/assignments/_support/sort_none.gif]
Reference [https://www.iana.org/assignments/_support/sort_none.gif]




         …     snip snap   …
11 000xxx
0
FRAG1 -- Fragmentation Header (first)
[RFC4944<http://www.iana.org/go/rfc4944>][RFC8025<http://www.iana.org/go/rfc8025>;]
11 000xxx
1-14
Unassigned
11 000xxx
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>;]
11 001000 through 11 011111
0-14
Unassigned
11 001000 through 11 011111
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>;]
11 100xxx
0
FRAGN -- Fragmentation Header (subsequent)
[RFC4944<http://www.iana.org/go/rfc4944>][RFC8025<http://www.iana.org/go/rfc8025>;]
11 100xxx
1-14
Unassigned
11 100xxx
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>;]
11 101000 through 11 101111
0-14
Unassigned
11 101000 through 11 101111
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>;]
11 11xxxx
0-15
Page switch
[RFC8025<http://www.iana.org/go/rfc8025>;]



   In the following sections, the semantics of "datagram_tag" are
   unchanged from [RFC4944] Section 5.3.

LT: I disagree on the world semantic, since the datagram tag is changed hop by hop. The receiver does not receive the one sent by the originator. It could be said that dtag is used to identify fragments belonging to a same packet, but the value by itself is changed during the fragment transmission.

PT> you right. What about:
          In the following sections, a "datagram_tag" extends the semantics defined in
    <xref target="RFC4944"/> Section 5.3."Fragmentation Type and Header".
    The datagram_tag is a locally unique identifier for the datagram from the
    perspective of the sender. This means that the datagram-tag identifies a
    datagram uniquely in the network when associated with the source of the
    datagram. As the datagram gets forwarded, the source changes and the
    datagram_tag must be swapped as detailed in
       <xref target="I-D.ietf-6lo-minimal-fragment"/>.


   The first fragment is recognized by a sequence of 0; it carries its
   fragment_size and the datagram_size of the compressed packet, whereas
   the other fragments carry their fragment_size and fragment_offset.
   The last fragment for a datagram is recognized when its
   fragment_offset and its fragment_size add up to the datagram_size.

LT: The format of intermediary fragment is not clear to me, do you have only DTAG and sequence? Why fragment size is necessary is it to remove padding? Why do you need to have offset and sequence, are they redundant?
Do you authorize overlapping fragments ? Can sequence be obtain as fragment_offset/fragment_size ?


  *   We removed the difference between the first and the next fragments that used to be there. As it goes the games of compressing the first fragment make it a variable length. The last one would need to be padded. Simplicity guided towards a variable fragment size. Which seems to help in some of the case of a PHY with variable MTU, a question that we discussed recently after the experience at LPWAN.
  *   The offset and size could be avoided if fragemnts are of a same size and are received in order. If not, the offset is useful to be able to place the data at the right offset in the recomposition buffer.

Ø  Nothing prevents overlapping with the current spec. Here’s an example of where it could be useful: frag 5 of 200 bytes is sent, MTU changes to 100, frag 5 appears to be discarded on the way, a new frag 5 of 100 bytes is sent followed by a frag 6. If the original frag 5 is received, then it overlaps with frag 6.

Ø  Proposed new text:
    The format of the fragment header is the same for all fragments.
    The format indicates both a length and an offset, which seem be redundant
    with the sequence field, but is not. The position of a fragment in the
    recomposition buffer is neither correlated with the value of the sequence
  field nor with the order in which the fragments are received.
   This enables misordered and overlapping fragments, e.g., a fragment 5 that
    is retried as smaller fragments 5, 13 and 14 due to a change of MTU.

    There is no requirement on the receiver to check for contiguity of the
    received fragments, and the sender MUST ensure that when all fragments
    are acknowledged, then the datagram is fully received.
    This may be useful in particular in the case where the MTU changes and a
    fragment sequence is retried with a smaller fragment_size, the remainder of
    the original fragment being retried with new sequence values.


      *  When set to 0, this field indicates an abort condition and all
         state regarding the datagram should be cleaned up once the
         processing of the fragment is complete; the processing of the
         fragment depends on whether there is a VRB already established
         for this datagram, and the next hop is still reachable:

         +  if a VRB already exists and is not broken, the fragment is
            to be forwarded along the associated Label Switched Path
            (LSP) as described in Section 7.2, but regardless of the
            value of the Sequence field;

         +  else, if the Sequence is 0, then the fragment is to be
            routed as described in Section 7.1 but no state is conserved
            afterwards.

LT: Not clear to me, the first point is an abort, but what is the purpose of the second point. 7.1 is not explicit on that.

  *   Second point is still equivalent to a forward and abort. It allows to clean up the path as determined by the IP address as opposed to the VRB, in case there is no VRB.
  *   Suggestion to add :
    In that case, the session if it exists is aborted and the packet is
    also forwarded in an attempt to clean up the next hops as along the
       path indicated by the IPv6 header (possibly including a routing header).




                            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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           RFRAG Acknowledgment Bitmap                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ^                   ^
        |                   |    bitmap indicating whether:
        |                   +--- Fragment with sequence 10 was received
        +----------------------- Fragment with sequence 00 was received
LT: could be good to use 12 instead of 10 to avoid confusion with a binary value.


  *   OK I used 9 to avoid shifting the drawing.


   Y: 1 bit; Explicit Congestion Notification Echo

LT : The rule to set the Y bit has to be specified. If you have a congestion, you risk to mark several fragments with a X bit, forcing the receiver to answer with that. It may increase the congestion is too much RFRAG are sent back.


  *   An asynchronous ack is an additional message that may avoid a number. The spec does not mention doing that, i.e., the ack is always triggered by the source. Should we add an async ack?
  *   If so I agree that it should be done very carefully, e.g., if the datagram size indicates a number of frags left to be received.
  *

LT: Make a reference to Annex C

  *   OK


   The 6LoWPAN endpoint that fragments the packets at 6LoWPAN level (the
   sender) also controls when the reassembling end point sends the RFRAG
   Acknowledgments by setting the Ack Requested flag in the RFRAG
   packets.  It may set the Ack Requested flag on any fragment to



  *   As you see with the current spec the ack is not asynchronously emitted by the receiver e.g. upon ECN.
  *   I suggested clarifying text like:

          The RFRAG Acknowledgment can optionally carry an ECN indication for flow
    control (see <xref target="onECN"/>). The receiver of a fragment with the
    'E' (ECN) flag set MUST echo that information by setting the 'E' (ECN) flag
     in the next RFRAG Acknowledgment.

   perform congestion control by limiting the number of outstanding
   fragments, which are the fragments that have been sent but for which
   reception or loss was not positively confirmed by the reassembling
   endpoint.  When the sender of the fragment knows that an underlying
   link-layer mechanism protects the Fragments, it may refrain from
   using the RFRAG Acknowledgment mechanism, and never set the Ack
   Requested bit.  When it receives a fragment with the ACK Request flag
   set, the 6LoWPAN endpoint that reassembles the packets at 6LoWPAN
   level (the receiver) sends back an RFRAG Acknowledgment to confirm
   reception of all the fragments it has received so far.

LT: What do you send when your packet has been entirely sent and the ACK has not been received ?


  *   Good point. The idea was always to retry the packet that carries the ack and that as long as that ack is not received the next window cannot open. What about:

    The Ack Requested bit marks the end of a window. It SHOULD be set on the

    last fragment to protect the datagram, and MAY be used in intermediate

    fragments for the purpose of flow control. This ARQ process SHOULD be

    protected by a timer, and the fragment that carries the ACK Request flag MAY

    be retried upon time out a configurable amount of times.

    Upon exhaustion  of the retries the sender may either abort the

    transmission of the datagram or retry the datagram from the first

    fragment with an ACK Request in order to reestablish a path and discover

     which fragments were received over the old path.



   The sender transfers a controlled number of fragments and MAY flag
   the last fragment of a series with an RFRAG Acknowledgment Request.
   The receiver (typo)

MUST acknowledge a fragment with the acknowledgment
   request bit set.  If any fragment immediately preceding an
   acknowledgment request is still missing, the receiver MAY
   intentionally delay its acknowledgment to allow in-transit fragments
   to arrive.

LT: can you have such behavior if all the fragments follow the same path.

  *   Rare but not impossible. An implementation may rotate packets when doing retries. It could also be that due to a previous ack the retries are already in the pipe. We just allow for it.



   When the sender decides that a packet should be dropped and the
   fragmentation process canceled, it sends a pseudo fragment with the
   fragment_offset, sequence and fragment_size all set to 0, and no
   data.  Upon reception of this message, the receiver should clean up
   all resources for the packet associated to the datagram_tag.  If an
   acknowledgment is requested, the receiver responds with a NULL
   bitmap.

LT: How the cleanup is done is connectivity to the next hop is lost?

  *   The reassembly buffer in intermediate hops is protected by a timer, that’s part of 6lo-minimal-fragment



   Either way, if the RFRAG-ACK indicates either an error (NULL bitmap)
   or that the fragment was entirely received (FULL bitmap), arms a
   short timer, and upon timeout, the VRB and all associate state are
   destroyed.  During that time, fragments of that datagram may still be
   received, e.g. if the RFRAG-ACK was lost on the way back and the
   source retried the last fragment.  In that case, the router sends an
   abort RFRAG-ACK along the Reverse LSP to complete the clean up.

LT: what happens if the routing is not changing, but the modulation is changing to shorten the MTU ?


  *   That’s OK as long as you have space in the sequence. You retry one fragment smaller with the original sequence and retry the other tiles with new sequences. The sequences are not expected to mean contiguous. What about adding:

     This specification does not provide a method to discover the number of hops

     or the minimal value of MTU along those hops. But should the minimal MTU

    decrease, it is possible to retry a long fragment (say sequence of 5) with

    first a shorter fragment of the same sequence (5 again) and then one or

    more other fragments with a sequence that was not used before (e.g., 11 and

     12).





   Optional congestion control

      The aggregation of multiple concurrent flows may lead to the
      saturation of the radio network and congestion collapse.

      The recovery mechanism should provide means for controlling the
      number of fragments in transit over the LLN.

LT: Path is stable and communications are symmetrical


  *   Well bidirectional but not really symmetrical.

LT: MTU do not change during the fragmentation due to a modulation change.


  *   We can live with that actually.





Many thanks Laurent!

You gave both the questions and the hints for the answers, that was cool.

As usual you forced me to think a lot and the exchange yields great improvements as well as useful clarification.

Please let me know if you’re OK and I’ll publish.

Take care,



Pascal