[6lo] Question on draft-ietf-6lo-fragment-recovery and VRB
Martine Lenders <m.lenders@fu-berlin.de> Fri, 30 August 2019 09:41 UTC
Return-Path: <m.lenders@fu-berlin.de>
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 0B8D8120124 for <6lo@ietfa.amsl.com>; Fri, 30 Aug 2019 02:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 GkSGfxvl52IY for <6lo@ietfa.amsl.com>; Fri, 30 Aug 2019 02:41:28 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 227AC12004F for <6lo@ietf.org>; Fri, 30 Aug 2019 02:41:28 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for 6lo@ietf.org with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from <m.lenders@fu-berlin.de>) id <1i3dPK-001WoC-93>; Fri, 30 Aug 2019 11:41:26 +0200
Received: from mail-ot1-f45.google.com ([209.85.210.45]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for 6lo@ietf.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (envelope-from <m.lenders@fu-berlin.de>) id <1i3dPJ-002Fng-K6>; Fri, 30 Aug 2019 11:41:26 +0200
Received: by mail-ot1-f45.google.com with SMTP id 97so3506264otr.4 for <6lo@ietf.org>; Fri, 30 Aug 2019 02:41:25 -0700 (PDT)
X-Gm-Message-State: APjAAAU+kL3c2RVzV83ol36ZUh5lC2l1X/t562ekN+C0KUMdRuRu8lnY bBh/nr/nmX0CdGdi7v9pcecq0LLeP7oqSbljW0c=
X-Google-Smtp-Source: APXvYqxxtGu/u13vk05suF07BI71l3co6fN6Z7hE7XepczRty6XHwFk2XGKWK28I/hOW3io6xfW+85ACI8Fs2kj9D9A=
X-Received: by 2002:a05:6830:1d75:: with SMTP id l21mr10845374oti.121.1567158084514; Fri, 30 Aug 2019 02:41:24 -0700 (PDT)
MIME-Version: 1.0
From: Martine Lenders <m.lenders@fu-berlin.de>
Date: Fri, 30 Aug 2019 11:40:48 +0200
X-Gmail-Original-Message-ID: <CALHmdRxLUXy9g94iYn+7Ujmr+0bmBR0Oo3psbHcZOauT08rOHg@mail.gmail.com>
Message-ID: <CALHmdRxLUXy9g94iYn+7Ujmr+0bmBR0Oo3psbHcZOauT08rOHg@mail.gmail.com>
To: 6lo@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ef39b20591526cff"
X-Originating-IP: 209.85.210.45
X-ZEDAT-Hint: A
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/DLCTxC2X4bRNtYPHhtEkavMWlz4>
Subject: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB
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: Fri, 30 Aug 2019 09:41:30 -0000
Hi, I have an implementation question for the virtual reassembly buffer with regards to [draft-ietf-6lo-fragment-recovery]. Section 6.1 of this draft states that a tuple (source address, tag) is used to identify a VRB entry and cites [draft-ietf-6lo-minimal-fragment] for that. However, as far as I understand [draft-ietf-6lo-minimal-fragment] and [draft-ietf-lwig-6lowpan-virtual-reassembly] this is not the case. [draft-ietf-6lo-minimal-fragment] doesn't mention VRB entry identification and only refers to [draft-ietf-lwig-6lowpan-virtual-reassembly]. That in turn only recounts the classic (source address, destination address, size, tag) tuple defined in RFC4944 and states that the only difference between the classic and VRB is the lack of the reassembled packet and addition of the next hop's address and the newly assigned tag: To reduce the memory requirement for reassembly buffers, the implementation > may opt to not keep the actual packet data in the reassembly buffer. > Instead, it may attempt to send out the data for a fragment in the form of > a forwarded fragment, as soon as all necessary information for that is > available. Obviously, all fragments need to be sent with the same outgoing > address (otherwise a full reassembly implementation would discard the > fragments) and the same datagram_tag. So my question is: Is the tuple definition in [draft-ietf-6lo-fragment-recovery] really correct? For exclusion datagram size I agree that it could be somewhat redundant. However, a node could have multiple destination addresses (either via multiple interfaces or IEEE-802.15.4-style short and long address). So, as the tag is link-specific (defined by a (source, destination) tuple), there could be distinct datagrams that have the same tuple (source, tag), or am I missing something? I already implemented the VRB with draft-ietf-6lo-minimal-fragment in mind and thus used the classic 4-tuple for indexing. But now I'm wondering: Can I reduce its index or would that be not advised? Kind regards, Martine
- [6lo] Question on draft-ietf-6lo-fragment-recover… Martine Lenders
- Re: [6lo] Question on draft-ietf-6lo-fragment-rec… Pascal Thubert (pthubert)
- Re: [6lo] Question on draft-ietf-6lo-fragment-rec… Martine Lenders
- [6lo] Paper on minimal fragment forwarding (was Q… Martine Lenders