Hello again Dave
Following up let me propose changes; the updated draft text in full is at
https://github.com/twatteyne/draft-watteyne-6lo-minimal-fragment/blob/master/draft-ietf-6lo-minimal-fragment-05.txt
Main changes:
An intro section as follows
1. Introduction
The original 6LoWPAN fragmentation is defined in [6LoWPAN] and it is
implicitly defined for use over a single IP hop through possibly
multiple Layer-2 (mesh-under) hops in a meshed 6LoWPAN Network.
Although [6LoWPAN-HC] updates [6LoWPAN], it does not redefine 6LoWPAN
fragmentation.
This means that over a Layer-3 (route-over) network, an IP packet is
expected to be reassembled at every hop at the 6LoWPAN sublayer,
pushed to Layer-3 to be routed, and then fragmented again if the next
hop is another similar 6LoWPAN link. This draft introduces an
alternate approach called 6LoWPAN Fragment Forwarding (FF) whereby an
intermediate node forwards a fragment as soon as it is received if
the next hop is a similar 6LoWPAN link. The routing decision is made
on the first fragment, which has all the IPv6 routing information.
The first fragment is forwarded immediately and a state is stored to
enable forwarding the next fragments along the same path.
Done right, 6LoWPAN Fragment Forwarding techniques lead to more
streamlined operations, less buffer bloat and lower latency. It may
be wasteful if some fragments are missing after the first one since
the first fragment will still continue till the 6LoWPAN endpoint that
will attempt to perform the reassembly, and may be misused to the
point that performances fall behind that of per-hop recomposition.
This specification provides a generic overview of FF, discusses
advantages and caveats, and introduces a particular 6LoWPAN Fragment
Forwarding technique called Virtual Reassembly Buffer that can be
used while conserving the message formats defined in [6LoWPAN].
And an intermediate section before VRB as follows:
4. Forwarding Fragments
A 6LoWPAN Fragment Forwarding technique makes the routing decision on
the first fragment, which is always is the one with the IPv6 address
of the destination. Upon a first fragment, a node creates a state
and forwards the fragment. The state is then used to forward the
next fragments of the datagram. Since the datagram_tag is uniquely
associated to the source Link-Layer address of the fragment, node B
must assign a new datagram_tag from iuts own namespace for the next
hop and rewrite the fragment header of each fragments with that
datagram_tag.
Compared to Section 2, the conceptual reassembly buffer in node B now
contains, assuming that node B is neither the source nor the final
destination:
* a datagram_tag as received in the incoming fragments, associated
to Link-Layer address of node A for which the received
datagram_tag is unique,
* the Link-Layer address that node B uses as source to forward the
fragments
* the Link-Layer address of the next hop C that is resolved on the
first fragment
* a datagram_tag that node B uniquely allocated for this datagram
and that is used when forwarding the fragments of the datagram
* the actual packet data from the fragments received so far, in a
form that makes it possible to detect when the whole packet has
been received and can be processed or forwarded,
* a datagram_size,
* a buffer for the remainder of a previous fragment left to be sent,
* a timer that allows discarding a partially reassembled packet
after some timeout.
A node that has not received the first fragment cannot forward the
next fragments. This means that if node B receives a fragment, node
A was in possession of the first fragment at some point. In order to
keep the operation simple, it makes sense to be consistent with
[6LoWPAN] and enforce that the first fragment is always sent first.
When that is done, if node B receives a fragment that is not the
first and for which it has no state, then node B should treat this as
an error and refrain from creating a state or attempting to forward.
This also means that node A should perform all its possible retries
on the first fragment before it attempts to send the next fragments,
and that it should abort the datagram and release its state if it
fails to send the first fragment.
One benefit of Fragment Forwarding is that the memory that is used to
store the packet is now distributed along the path, which limits the
buffer bloat effect. Multiple fragments may progress in parallel
along the network as long as they do not interfere. An associated
caveat is that on a half duplex radio, if node A sends the next
fragment at the same time as node B forwards the previous fragment to
a node C down the path then node B will miss the next fragment. If
node C forwards the previous fragment to a node D at the same time
and on the same frequency as node A sends the next fragment to node
B, this may result in a hidden terminal problem at B whereby the
transmission from C interferes with that from A unbeknownst of node
A. It results that consecutive fragments must be reasonably spaced
in order to avoid the 2 forms of collision described above. A node
that has multiple packets or fragments to send via different next-hop
routers may interleave the messages in order to alleviate those
effects.
Does that sound right?
Pascal
From: Dave Thaler <[email protected]>
Sent: vendredi 8 novembre 2019 00:44
To: Pascal Thubert (pthubert) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
Follow ups below
From: Pascal Thubert (pthubert) <[email protected]>
Please see in-line
Le 7 nov. 2019 à 22:22, Dave Thaler
<[email protected]<mailto:[email protected]>> a écrit :
Responses inline below.
Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> 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.
That’s not how I read the document right now.
First, this document as written does not specify any behavior itself, since the
document is listed as Informational only, and contains no normative references.
Second, I read section 1-2 as analysis/discussion/issues around the normative
behavior stated in [RFC4944], and section 3 as analysis/discussion/issues
around the normative behavior stated in
[I-D.ietf-lwig-6lowpan-virtual-reassembly<https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04#ref-I-D.ietf-lwig-6lowpan-virtual-reassembly>].
If the WG’s intent for this document is to actually specify behavior, or
behavior changes, in this document, then it should use 2119 language, and have
normative references, so one can claim compliance to it.
And the document would require more changes than I originally expected or
argued for in my review.
> 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.
See my points above about “we is this draft” meaning this draft needs to be a
lot clearer that it is specifying behavioral changes that one can conform to.
I read the text as explaining what RFC 4944 itself requires. Specifically the
last sentence of the section the text above is quoted from explicitly says
“That is, the packet is fully reassembled, then (re)fragmented, at every hop.”
That’s what I’m reacting to since the bullet list is very wasteful when fully
reassembled at each hop, which is the context of this section.
Furthermore, it’s arguably broken since looking up the next hop when the first
fragment arrives, and then only using it once all fragments
have arrived and the packet can be fully reassembled, means the next hop
information can be stale at that point and you’re forwarding it
to the wrong place, or even a place that no longer exists at that time.
The notion of forwarding each fragment as it’s received, without reassembling,
starts in section 3, which is the alternative being compared
(as I read it) with the stock 4944 approach. It’s only then that “resolve next
hop on first fragment received” makes any sense to me, not back in section 1.
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.
That’s not my reading of the existing text. My reading is of this doc is that
[I-D.ietf-lwig-6lowpan-virtual-reassembly<https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04#ref-I-D.ietf-lwig-6lowpan-virtual-reassembly>]
is what covers that behavior (as the first paragraph of section 3 the 6lo draft
explains) and the 6lo draft is just analyzing it.
If the intent Is to specify it normatively in the 6lo draft, then I believe
this draft needs more work
before being ready.
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.
Not sure that “this” refers to. See above. Section 1-2 are currently written
to be about the case where you reassemble at each hop.
[…]
Dave
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
