Hello again Benjamin
You really made those drafts I'm editing a lot better by your keen reviews and
this is another incredible one. Many thanks!!!
Let's go with the Discuss to start with?
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> In Section 2.3 we refer to the datagram_tag plus layer-2 sender address as
> being "a globally unique identifier for the datagram", but I think this can
> only
> hold within some time-bounded window (e.g., the lifetime of the packet), since
> the tag space is finite and reuse somewhat inevitable. [The simplest way to
> resolve this is probably to just remove the definition from this document and
> refer to draft-ietf-6lo-minimal-fragment for definitions.]
Rightly so. I changed the text on the minimal draft as
"
"LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
introduces the generic concept of a Virtual Reassembly Buffer (VRB)
and specifies behaviours and caveats that are common to a large
family of FF techniques including this, which fully inherits from
that specification. It also defines terms used in this document:
6LoWPAN endpoints, Compressed Form, Datagram_Tag, Datagram_Size, and
Fragment_Offset.
"
>
> I think we should be more clear about whether a "FULL bitmap" always has
> 32 bits set to one, or if "merely" having as many bits as the sender sent
> fragments set to one also counts as "FULL". The current text seems to invite
> different interpretations by implementations. (If FULL does mean all 32 bits,
> then the semantics of the other case seem unclear to
> me.)
There's a definition and we need to stick to it:
FULL bitmap: Refers to a bitmap with all bits set to one.
The problem is that we do not say (or even know in advance) how many fragments
there are, total. The MTU may change.
So even if all fragments are acknowledged with a bit set, an intermediate node
cannot fathom if that's the end or if there's more to come. But the end-points
know. The receiver will see that all bytes up to Datagram-Size are received so
it has it all.
The spec asks the receiver to use a FULL bitmap instead of setting only the
bits corresponding to the received fragments so the intermediate nodes know
that the process is complete.
To clarify I'm adding the last sentence in the text below:
"
When enough fragments are received to cover the whole datagram, the
receiving endpoint reconstructs the packet, passes it to the upper
layer, sends an RFRAG Acknowledgment on the reverse path with a FULL
bitmap, and arms a short timer, e.g., on the order of an average
round-trip delay in the network. The FULL bitmap is used as opposed
to a bitmap that acknowledges only the received fragments to let the
intermediate nodes know that the datagram is fully received.
"
>
> What's the transition/backwards-compatibility story? That is, how does a
> sender know that all nodes on the path support the RFRAG dispatch types, and
> what happens if they are sent anyway and get to a node that doesn't
> implement them?
It has to be management and configuration or alliance games. There is no
negotiation.
There is no overarching 6LoWPAN protocol that can advertise capabilities though
we're building one for RPL.
Same goes for all the prior changes to 6LoWPAN, e.g., RFC 8025.
In practice there is no 6LoWPAN network. There's an ISA100.11a network, a
ZigbeeIP network, a Thread network, or a WiSUN network. Those alliances specify
a particular bundle of functionalities from a bunch of RFCs and build their
compliance tests on that. If Thread decides that the RFRAGs are used, then all
the nodes are capable of it.
But that's a long story to make in the RFC just to say we do nothing. Do we
really want that?
> I have grave misgivings about allowing a packet (as identified by sender and
> tag) to be refragmented by the sender so that a single fragment sequence
> number is used for fragments of different lengths. We do not seem to provide
> a mechanism to distinguish which variant of that fragment is being ack'd,
> which could lead to disagreement between sender and receiver as to whether a
> full packet is reconstructed.
Yes, that makes sense. And the change is simple to do and appears harmless.
Note that if the second is smaller than and included within the first, it does
not matter which is received. I just did not expect that people would reuse the
seq for a larger fragment in which case there may be an issue. I just hope
people did not implement that piece yet.
Note that the FULL bitmap hides the lack of continuity from intermediate nodes.
I also wish to avoid duplication in the example so we get
"
This enables
refragmenting to cope with an MTU deduction, see the example of the
fragment seq. 5 that is retried end-to-end as smaller fragments seq.
13 and 14 in Section 6.2."
And in Section 6.2
"
This specification does not provide a method to discover the number
of hops or the minimal value of MTU along those hops. But should the
minimal MTU decrease, it is possible to retry a long fragment (say
Sequence of 5) with several shorter fragments with a Sequence that
was not used before (e.g., 13 and 14). Fragment 5 is marked as
abandoned and will not be retried anymore. Note that Path MTU
Discovery is out of scope for this document.
"
> Brainstorming, it might be possible to allow such refragmenting at the sender
> by using a Fragment_Size of zero to indicate "this fragment is superseded" and
> allocating new sequence number for all its components.
> (I didn't attempt to do an exhaustive check on whether that proposal is flawed
> and Fragment_Size of zero already has some existing semantics that would be
> in conflict.)
>
Well the proposal is just to ignore the original fragment. The set of fragments
is used to figure if everything is sent and what may need resend. It is
expected that there will be overlaps and now gaps in the acknowledgements. The
FULL bitmap (all ones) is the indicator that enough was received without
ambiguity and regardless of which fragments were used.
Works?
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
