[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