Re: [6lo] Intdir last call review of draft-ietf-6lo-minimal-fragment-04

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Dave

Continued below

Le 13 nov. 2019 à 04:28, Dave Thaler <[e-mail]> a écrit :




From: Pascal Thubert (pthubert) <[e-mail]>
Sent: Friday, November 8, 2019 5:25 AM
To: Dave Thaler <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftwatteyne%2Fdraft-watteyne-6lo-minimal-fragment%2Fblob%2Fmaster%2Fdraft-ietf-6lo-minimal-fragment-05.txt&data=02%7C01%7Cdthaler%40microsoft.com%7Ce5e6570b9eaf446511d308d7644f0bd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637088162986168475&sdata=KeNcyTWQvwKkEP9AivyWKp2d1K9uAOVhmAmcnKeRsJs%3D&reserved=0>


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].

Looks good so far.  I presume that [6LoWPAN] will then be a normative reference,
based on that wording, correct?


Correct. That’s RFC 4944. The VRB draft also becomes normative.

And would the draft be a standards track doc, or what?


I asked for a slot at 6lo to discuss your points. That would be a key one to agree with the group.



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

Grammar problem above: “is always is”

Fixed

   of the destination.  Upon a first fragment, a node creates a state
   and forwards the fragment.

I’d recommend “a node *attempts to* create state and forward the fragment”,
since either of those could potentially fail, right?

Also should this use normative language (“a node MUST…”)?

The state is then used to forward the
   next fragments of the datagram.


I’d suggest MAY attempt to create the state and if successful MUST use it to forward the next fragments.


There’s a logic bug here in that you’re missing saying what happens if that state doesn’t exist.
E.g., “When a node receives a fragment other than a first fragment, it MUST look up
state based on the source Link-Layer address and the datagram_tag in the received fragment.
If no such state is found, the fragment MUST be dropped; otherwise the fragment MUST be
forwarded using the information in the state found.”

Used verbatim


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

Typo: “iuts”


Fixed

   hop and rewrite the fragment header of each fragments with that

Grammar: “each fragments” -> “each fragment”

Fixed


   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,

Since each fragment is forwarded separately, the above bullet looks confusing.
Why do you care “when the whole packet … can be … forwarded” since you
don’t forward whole packets?

Yes, my mistake. Removed that line.


   *  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.

Same confusion here.  Why would you have a partially “reassembled” packet
if you forward fragments without reassembling at this node?

That’s specific to the VRB method that might store a piece of a previous fragment. In general we need to timeout the state to clean it. Replaced the partially reassembled by the FF state


   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

The use of “should” is ambiguous.  Do you mean SHOULD or MUST?

Removed « should « since your verbatim text already covers this now.



  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

I hope you’ll be able to attend 6lo. We need to clarify the goal of the draft and the target info vs. std track.

All the best,

Pascal



From: Dave Thaler <[e-mail]<mailto:[e-mail]>>
Sent: vendredi 8 novembre 2019 00:44
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04

Follow ups below

From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Please see in-line

Le 7 nov. 2019 à 22:22, Dave Thaler <[e-mail]<mailto:[e-mail]>> a écrit :

Responses inline below.

Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-minimal-fragment-04%23ref-I-D.ietf-lwig-6lowpan-virtual-reassembly&data=02%7C01%7Cdthaler%40microsoft.com%7Ce5e6570b9eaf446511d308d7644f0bd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637088162986178431&sdata=cTGayubx94CV8nUsN3fmXOTKg5cQrD%2BdsVFmrvxlh%2BA%3D&reserved=0>].
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-minimal-fragment-04%23ref-I-D.ietf-lwig-6lowpan-virtual-reassembly&data=02%7C01%7Cdthaler%40microsoft.com%7Ce5e6570b9eaf446511d308d7644f0bd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637088162986178431&sdata=cTGayubx94CV8nUsN3fmXOTKg5cQrD%2BdsVFmrvxlh%2BA%3D&reserved=0>]
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