Re: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB

Martine Lenders <m.lenders@fu-berlin.de> Fri, 30 August 2019 12:48 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 67D3D120086 for <6lo@ietfa.amsl.com>; Fri, 30 Aug 2019 05:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 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, URIBL_BLOCKED=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 mUwT1dVA7JS9 for <6lo@ietfa.amsl.com>; Fri, 30 Aug 2019 05:48:33 -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 49B31120B6D for <6lo@ietf.org>; Fri, 30 Aug 2019 05:48:33 -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 <1i3gKN-002dOj-Ay>; Fri, 30 Aug 2019 14:48:31 +0200
Received: from mail-oi1-f182.google.com ([209.85.167.182]) 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 <1i3gKM-002nbE-PE>; Fri, 30 Aug 2019 14:48:31 +0200
Received: by mail-oi1-f182.google.com with SMTP id a127so5250340oii.2 for <6lo@ietf.org>; Fri, 30 Aug 2019 05:48:30 -0700 (PDT)
X-Gm-Message-State: APjAAAW1Mlx4ovFTMaj0VGFFXyfVAe4Y/ZwSgduNg8SopJZzbJVnrsaH ItfH9uVwrLFMBe50GYQ6LTXCcBsZB2oKOdu+CmM=
X-Google-Smtp-Source: APXvYqz/ndBH7FO0W6xuiUgj7QfF4jyw+ACaXNIcIFwNktEJ+VyIKyfgfI46SHLIIa/s4yizc9KyXgdcei6wYUm5QVQ=
X-Received: by 2002:aca:2313:: with SMTP id e19mr10116491oie.2.1567169309579; Fri, 30 Aug 2019 05:48:29 -0700 (PDT)
MIME-Version: 1.0
References: <CALHmdRxLUXy9g94iYn+7Ujmr+0bmBR0Oo3psbHcZOauT08rOHg@mail.gmail.com> <MN2PR11MB35658D8325E730B3FD593019D8BD0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35658D8325E730B3FD593019D8BD0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Martine Lenders <m.lenders@fu-berlin.de>
Date: Fri, 30 Aug 2019 14:47:53 +0200
X-Gmail-Original-Message-ID: <CALHmdRwnK2jjs7vUfpk-b=teW9TyFds_n2SwBN_-VNn2s+ovUw@mail.gmail.com>
Message-ID: <CALHmdRwnK2jjs7vUfpk-b=teW9TyFds_n2SwBN_-VNn2s+ovUw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000020740591550a1c"
X-Originating-IP: 209.85.167.182
X-ZEDAT-Hint: A
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/gdeZakcGa9Dlv9D643eWwSsRBwM>
Subject: Re: [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 12:48:36 -0000

Thanks for your quick response!

Cheers,
Martine

Am Fr., 30. Aug. 2019 um 13:44 Uhr schrieb Pascal Thubert (pthubert) <
pthubert@cisco.com>;:

> Hello Martine
>
>
>
> Great to hear about your implementation. The group is interested to learn
> about your progress (keep us tuned) and happy to help you through. P
>
> lease do not hesitate to ask for more clarification as you feel needed.
> Even if you’re not too sure you should ask, if you wonder there’s probably
> a reason and you’re helping the implementors who will be following you.
>
>
>
> Please see below:
>
>
>
> 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.
>
> Ø    Correct, and the meaning is source MAC address not source IP
> address. The exact sentence is
>
> Ø                                       Upon a first fragment (i.e. with a
>
> Ø     sequence of zero), a VRB and the associated LSP state are created for
>
> Ø     the tuple (source MAC address, datagram_tag) and the fragment is
>
> Ø     forwarded along the IPv6 route that matches the destination IPv6
>
> Ø     address in the IPv6 header as prescribed by
>
> Ø     [I-D.ietf-6lo-minimal-fragment <https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05#ref-I-D.ietf-6lo-minimal-fragment>].
>
> Ø
>
> 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].
>
>    - It would not hurt to mention it though. Interesting. Minimal has:”
>    All fragments are tagged with a 16-bit
>
>    "    Each datagram can be uniquely identified by the source and final
>
>    destination link-layer addresses of the frame that carries it, the
>
>    fragment size and the datagram_tag.
>
>
>
> Ø    That’s  misleading… I’ll correct it.
>
> That in turn only recounts the classic (source address, destination
> address, size, tag) tuple defined in RFC4944
>
>    - When receiving a fragment, the destination is self and the size may
>    vary from a datagram to the next. So the only thing that really identify
>    the datagram is the source MAC and the tag.
>
> 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:
>
> Ø    Actually the forwarder sends the datagram with self as source to the
> source mac address is swapped naturally. It has to set the next hop’s mac
> address and the swapped datagram tag. The next hop’s MAC address identifies
> the node that should receive the packet and the datagram tag together with
> the source mac identify the reassembly buffer within the receiver. There is
> no contradiction.
>
> 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?
>
>
>
>    - It is.
>
>
>
> 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?
>
>
>
> Ø    Yes, the role of the destination MAC address is to reach the next
> hop, but does not change the processing within that node. I could change
> the L2 address I use to refer to the next hop in the middle of a fragmented
> packet, it is still the same fragmented packet. In other words, please do
> not use the dmac as to index the VRB. From your question I think the LWIG
> draft should clarify, and we can change minimal draft to clarify as well.
>
>
>
> 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?
>
>
>
> Ø    You should reduce the index : ) There can not be 2 different
> datagrams coming in parallel from a same previous hop and with a same
> datagram tag. There must be a sentence somewhere in the LWIG draft that
> says that a new and currently unused datagram tag is chosen for a new
> incoming datagram, correct?  Minimal says
>
> Ø                                                                Upon
>
> Ø     receiving a fragment from node A with a datagram_tag previously
>
> Ø     unseen from node A, node B allocates a buffer large enough to hold
>
> Ø     the entire packet.
>
>
>
> Ø    This text only indexes the VRB with any identifier of node A and the
> tag… And this is correct. What’s a bit more ugly is that Node A should not
> change the source MAC in between fragments because that will confise node
> B. I need to add text on that too.
>
>
>
>
>
> Many thanks Martine for raising all this, and all the best for your
> implementation.
>
>
>
> Pascal
>