Hello Laurent
Many thanks for your review : )
Let’s see below
a new protocol. However, adding that capability alone to the local
implementation of the original 6LoWPAN fragmentation would not
address the
bulk of the issues raised against it, and may create new
issues like remnant state in the network.
LT: can you specify or give some references.
PT> well there are papers such as Georgios’, but it is unusual to add such
reference in an RFC.
Still I agree as such it is open ended. What about:
However, adding that capability alone to the local implementation of the
original 6LoWPAN fragmentation would not address the issues of resources
locked and wasted transmissions due to the loss of a fragment.
<xref target="RFC4944"/> does not define a mechanism to first discover a
fragment loss, and then to recover that loss. With RFC 4944, the
forwarding of a whole datagram fails when one fragment is not delivered
properly to the destination 6LoWPAN endpoint. Constrained memory
resources are blocked on the receiver until the receiver times out.
That problem is exacerbated when forwarding fragments over multiple hops
since a loss at an intermediate hop will not be discovered by either the
source or the destination, and the source will keep on sending
fragments,
wasting even more resources in the network and possibly contributing to
the condition that caused the loss to no avail since the datagram cannot
arrive in its entirety.
(to be confirmed by IANA) The new 6LoWPAN Dispatch types use the
Value Bit Pattern of 11 1010xx from page 0 [RFC8025], as follows:
Pattern Header Type
+------------+------------------------------------------+
| 11 101000 | RFRAG - Recoverable Fragment |
| 11 101001 | RFRAG-ARQ - RFRAG with Ack Request |
| 11 101010 | RFRAG-ACK - RFRAG Acknowledgment |
| 11 101011 | RFRAG-ECHO - RFRAG Ack with ECN Echo |
+------------+------------------------------------------+
LT: This space is marked experimental use by IANA. Why not select a value in
another page (rfc 8025).
PT> Hum… no. The experimental is only for page 15. It is free in all pages
including 0. Sorry the table is a bit confusing to read due to that other
dimension (pages).
Bit Pattern [https://www.iana.org/assignments/_support/sort_none.gif]
Page [https://www.iana.org/assignments/_support/sort_none.gif]
Header Type [https://www.iana.org/assignments/_support/sort_none.gif]
Reference [https://www.iana.org/assignments/_support/sort_none.gif]
… snip snap …
11 000xxx
0
FRAG1 -- Fragmentation Header (first)
[RFC4944<http://www.iana.org/go/rfc4944>][RFC8025<http://www.iana.org/go/rfc8025>]
11 000xxx
1-14
Unassigned
11 000xxx
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>]
11 001000 through 11 011111
0-14
Unassigned
11 001000 through 11 011111
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>]
11 100xxx
0
FRAGN -- Fragmentation Header (subsequent)
[RFC4944<http://www.iana.org/go/rfc4944>][RFC8025<http://www.iana.org/go/rfc8025>]
11 100xxx
1-14
Unassigned
11 100xxx
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>]
11 101000 through 11 101111
0-14
Unassigned
11 101000 through 11 101111
15
Reserved for Experimental Use
[RFC8025<http://www.iana.org/go/rfc8025>]
11 11xxxx
0-15
Page switch
[RFC8025<http://www.iana.org/go/rfc8025>]
In the following sections, the semantics of "datagram_tag" are
unchanged from [RFC4944] Section 5.3.
LT: I disagree on the world semantic, since the datagram tag is changed hop by
hop. The receiver does not receive the one sent by the originator. It could be
said that dtag is used to identify fragments belonging to a same packet, but
the value by itself is changed during the fragment transmission.
PT> you right. What about:
In the following sections, a "datagram_tag" extends the semantics
defined in
<xref target="RFC4944"/> Section 5.3."Fragmentation Type and Header".
The datagram_tag is a locally unique identifier for the datagram from the
perspective of the sender. This means that the datagram-tag identifies a
datagram uniquely in the network when associated with the source of the
datagram. As the datagram gets forwarded, the source changes and the
datagram_tag must be swapped as detailed in
<xref target="I-D.ietf-6lo-minimal-fragment"/>.
The first fragment is recognized by a sequence of 0; it carries its
fragment_size and the datagram_size of the compressed packet, whereas
the other fragments carry their fragment_size and fragment_offset.
The last fragment for a datagram is recognized when its
fragment_offset and its fragment_size add up to the datagram_size.
LT: The format of intermediary fragment is not clear to me, do you have only
DTAG and sequence? Why fragment size is necessary is it to remove padding? Why
do you need to have offset and sequence, are they redundant?
Do you authorize overlapping fragments ? Can sequence be obtain as
fragment_offset/fragment_size ?
* We removed the difference between the first and the next fragments that
used to be there. As it goes the games of compressing the first fragment make
it a variable length. The last one would need to be padded. Simplicity guided
towards a variable fragment size. Which seems to help in some of the case of a
PHY with variable MTU, a question that we discussed recently after the
experience at LPWAN.
* The offset and size could be avoided if fragemnts are of a same size and
are received in order. If not, the offset is useful to be able to place the
data at the right offset in the recomposition buffer.
Ø Nothing prevents overlapping with the current spec. Here’s an example of
where it could be useful: frag 5 of 200 bytes is sent, MTU changes to 100, frag
5 appears to be discarded on the way, a new frag 5 of 100 bytes is sent
followed by a frag 6. If the original frag 5 is received, then it overlaps with
frag 6.
Ø Proposed new text:
The format of the fragment header is the same for all fragments.
The format indicates both a length and an offset, which seem be redundant
with the sequence field, but is not. The position of a fragment in the
recomposition buffer is neither correlated with the value of the sequence
field nor with the order in which the fragments are received.
This enables misordered and overlapping fragments, e.g., a fragment 5 that
is retried as smaller fragments 5, 13 and 14 due to a change of MTU.
There is no requirement on the receiver to check for contiguity of the
received fragments, and the sender MUST ensure that when all fragments
are acknowledged, then the datagram is fully received.
This may be useful in particular in the case where the MTU changes and a
fragment sequence is retried with a smaller fragment_size, the remainder of
the original fragment being retried with new sequence values.
* When set to 0, this field indicates an abort condition and all
state regarding the datagram should be cleaned up once the
processing of the fragment is complete; the processing of the
fragment depends on whether there is a VRB already established
for this datagram, and the next hop is still reachable:
+ if a VRB already exists and is not broken, the fragment is
to be forwarded along the associated Label Switched Path
(LSP) as described in Section 7.2, but regardless of the
value of the Sequence field;
+ else, if the Sequence is 0, then the fragment is to be
routed as described in Section 7.1 but no state is conserved
afterwards.
LT: Not clear to me, the first point is an abort, but what is the purpose of
the second point. 7.1 is not explicit on that.
* Second point is still equivalent to a forward and abort. It allows to
clean up the path as determined by the IP address as opposed to the VRB, in
case there is no VRB.
* Suggestion to add :
In that case, the session if it exists is aborted and the packet is
also forwarded in an attempt to clean up the next hops as along the
path indicated by the IPv6 header (possibly including a routing header).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^
| | bitmap indicating whether:
| +--- Fragment with sequence 10 was received
+----------------------- Fragment with sequence 00 was received
LT: could be good to use 12 instead of 10 to avoid confusion with a binary
value.
* OK I used 9 to avoid shifting the drawing.
Y: 1 bit; Explicit Congestion Notification Echo
LT : The rule to set the Y bit has to be specified. If you have a congestion,
you risk to mark several fragments with a X bit, forcing the receiver to answer
with that. It may increase the congestion is too much RFRAG are sent back.
* An asynchronous ack is an additional message that may avoid a number. The
spec does not mention doing that, i.e., the ack is always triggered by the
source. Should we add an async ack?
* If so I agree that it should be done very carefully, e.g., if the
datagram size indicates a number of frags left to be received.
*
LT: Make a reference to Annex C
* OK
The 6LoWPAN endpoint that fragments the packets at 6LoWPAN level (the
sender) also controls when the reassembling end point sends the RFRAG
Acknowledgments by setting the Ack Requested flag in the RFRAG
packets. It may set the Ack Requested flag on any fragment to
* As you see with the current spec the ack is not asynchronously emitted by
the receiver e.g. upon ECN.
* I suggested clarifying text like:
The RFRAG Acknowledgment can optionally carry an ECN indication for
flow
control (see <xref target="onECN"/>). The receiver of a fragment with the
'E' (ECN) flag set MUST echo that information by setting the 'E' (ECN) flag
in the next RFRAG Acknowledgment.
perform congestion control by limiting the number of outstanding
fragments, which are the fragments that have been sent but for which
reception or loss was not positively confirmed by the reassembling
endpoint. When the sender of the fragment knows that an underlying
link-layer mechanism protects the Fragments, it may refrain from
using the RFRAG Acknowledgment mechanism, and never set the Ack
Requested bit. When it receives a fragment with the ACK Request flag
set, the 6LoWPAN endpoint that reassembles the packets at 6LoWPAN
level (the receiver) sends back an RFRAG Acknowledgment to confirm
reception of all the fragments it has received so far.
LT: What do you send when your packet has been entirely sent and the ACK has
not been received ?
* Good point. The idea was always to retry the packet that carries the ack
and that as long as that ack is not received the next window cannot open. What
about:
The Ack Requested bit marks the end of a window. It SHOULD be set on the
last fragment to protect the datagram, and MAY be used in intermediate
fragments for the purpose of flow control. This ARQ process SHOULD be
protected by a timer, and the fragment that carries the ACK Request flag MAY
be retried upon time out a configurable amount of times.
Upon exhaustion of the retries the sender may either abort the
transmission of the datagram or retry the datagram from the first
fragment with an ACK Request in order to reestablish a path and discover
which fragments were received over the old path.
The sender transfers a controlled number of fragments and MAY flag
the last fragment of a series with an RFRAG Acknowledgment Request.
The receiver (typo)
MUST acknowledge a fragment with the acknowledgment
request bit set. If any fragment immediately preceding an
acknowledgment request is still missing, the receiver MAY
intentionally delay its acknowledgment to allow in-transit fragments
to arrive.
LT: can you have such behavior if all the fragments follow the same path.
* Rare but not impossible. An implementation may rotate packets when doing
retries. It could also be that due to a previous ack the retries are already in
the pipe. We just allow for it.
When the sender decides that a packet should be dropped and the
fragmentation process canceled, it sends a pseudo fragment with the
fragment_offset, sequence and fragment_size all set to 0, and no
data. Upon reception of this message, the receiver should clean up
all resources for the packet associated to the datagram_tag. If an
acknowledgment is requested, the receiver responds with a NULL
bitmap.
LT: How the cleanup is done is connectivity to the next hop is lost?
* The reassembly buffer in intermediate hops is protected by a timer,
that’s part of 6lo-minimal-fragment
Either way, if the RFRAG-ACK indicates either an error (NULL bitmap)
or that the fragment was entirely received (FULL bitmap), arms a
short timer, and upon timeout, the VRB and all associate state are
destroyed. During that time, fragments of that datagram may still be
received, e.g. if the RFRAG-ACK was lost on the way back and the
source retried the last fragment. In that case, the router sends an
abort RFRAG-ACK along the Reverse LSP to complete the clean up.
LT: what happens if the routing is not changing, but the modulation is changing
to shorten the MTU ?
* That’s OK as long as you have space in the sequence. You retry one
fragment smaller with the original sequence and retry the other tiles with new
sequences. The sequences are not expected to mean contiguous. What about adding:
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
first a shorter fragment of the same sequence (5 again) and then one or
more other fragments with a sequence that was not used before (e.g., 11 and
12).
Optional congestion control
The aggregation of multiple concurrent flows may lead to the
saturation of the radio network and congestion collapse.
The recovery mechanism should provide means for controlling the
number of fragments in transit over the LLN.
LT: Path is stable and communications are symmetrical
* Well bidirectional but not really symmetrical.
LT: MTU do not change during the fragmentation due to a modulation change.
* We can live with that actually.
Many thanks Laurent!
You gave both the questions and the hints for the answers, that was cool.
As usual you forced me to think a lot and the exchange yields great
improvements as well as useful clarification.
Please let me know if you’re OK and I’ll publish.
Take care,
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
