Hello Dave More below
Pascal Le 8 nov. 2019 à 00:44, Dave Thaler <[email protected]> a écrit : 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. Yes, I spotted that and already moved the LWIG draft and RFC 4944 to normative References when I handled your first run of comments. 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. The high level behaviour change is that fragments are forwarded before the whole message is received. The draft introduces the abstract technique and endorses the LWIG work as canonical to 6lo within that umbrella. It is also supposed to give more information on when to use FF and on caveats/pitfalls that may be encountered and precautions to be taken. Some gory details and optimizations that are internal to a box and could be implemented otherwise are left to the LWIG draft. The 6lo work on recoverable fragments is another way of achieving fragments forwarding. Both inherit from the FF draft and yield the same pitfalls. We discussed whether the draft should have been std track but the chairs recommended otherwise so we wrote it without BCP 14 terms. I guess it is still time to revise that. And the document would require more changes than I originally expected or argued for in my review. I’m willing to consider that very seriously. I’d wish to settle on those changes with you and then run the result through the group rather than the other way around. Would that work for you? Could we talk in Singapore ? > 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. Agreed. I guess the WG was clear on what we are doing beforehand and failed to spot this. I suggest adding introduction text that describes all we discussed here. 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. There’s some of that too. There’s a generic behavior and a particular way of implementing it that we present as an example. That’s probably why it was difficult to position this draft info vs std track. 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. […] Agreed 1 and 2 are a problem statement with current state of the art. This was your suggestion to receive all fragments before forwarding the first one. This recreates the bloat we avoid with this draft by streamlining fragments. All the best, Pascal Dave
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
