Hello Dave Continued below
Le 13 nov. 2019 à 04:28, Dave Thaler <[email protected]> a écrit : From: Pascal Thubert (pthubert) <[email protected]> Sent: Friday, November 8, 2019 5:25 AM To: Dave Thaler <[email protected]> Cc: [email protected]; [email protected]; [email protected] 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 <[email protected]<mailto:[email protected]>> Sent: vendredi 8 novembre 2019 00:44 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04 Follow ups below From: Pascal Thubert (pthubert) <[email protected]<mailto:[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://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
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
