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
