Subject: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

From: Martine Lenders <[email-masked]>
Date: Wed, 6 Feb 2019 15:49:05 +0100

Hi,

I'm currently in the process of implementing first prototypes of both
minimal fragment forwarding [1] and fragment recovery [2] for RIOT [3].

However, I'm unsure how I can determine when it is safe to remove a VRB
entry at least for the minimal forwarding case (even for a successfully
transmitted datagram). As far as I have seen not even the original VRB
draft [4] mentions a strategy for that.

For the success case I could of course just count the bytes of the
fragments and remove the VRB entry once I reach the datagram size, however
this does not account for possibly received duplicates (unless I keep track
of at least the intervals of all received fragments which of course costs
more memory).

The failure case is easier, since I could just use the timeout used in the
original 6Lo fragmentation, but using this for the success case as an
alternative to my proposal above might lead to a congestion of the VRB.

Are there any other strategies I might have missed?

Kind regards,
Martine Lenders

[1] https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/
[2] https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/
[3] https://github.com/RIOT-OS/RIOT
[4]
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Feb 2019 15:35:32 +0000

Hello Martine

Fragments follow a same path, but this is not a guarantee that they will not be mis-ordered. So whatever you do, it should not be immediate but done upon a time out because once the VRB is gone, packets are dropped. Note that if the first packet is delayed, then minimal-fragment is in trouble.

For fragment-recovery-01 there is text in 7.3 about cleaning the VRB, basically an ACK that indicates a reset of a complete reception (all 0 or all 1) triggers a short timer to destroy the VRB. This is done in case the ack is lost on the rest of the way back and the last flow is retried. There is also text at the end of section 6 that indicates that a reset by the sender may not have an rfrag-ack request bit set. In that case, the same operation as if the RFRAG ack was received applies. I could add a word on that.

All the best,

Pascal

From: 6lo <[email-masked]> On Behalf Of Martine Lenders
Sent: mercredi 6 février 2019 15:49
To: [email-masked]
Subject: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

Hi,

I'm currently in the process of implementing first prototypes of both minimal fragment forwarding [1] and fragment recovery [2] for RIOT [3].

However, I'm unsure how I can determine when it is safe to remove a VRB entry at least for the minimal forwarding case (even for a successfully transmitted datagram). As far as I have seen not even the original VRB draft [4] mentions a strategy for that.

For the success case I could of course just count the bytes of the fragments and remove the VRB entry once I reach the datagram size, however this does not account for possibly received duplicates (unless I keep track of at least the intervals of all received fragments which of course costs more memory).

The failure case is easier, since I could just use the timeout used in the original 6Lo fragmentation, but using this for the success case as an alternative to my proposal above might lead to a congestion of the VRB.

Kind regards,
Martine Lenders

[1] https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/
[2] https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/
[3] https://github.com/RIOT-OS/RIOT
[4] https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

---

From: Martine Lenders <[email-masked]>
Date: Wed, 6 Feb 2019 17:26:41 +0100

Hello Pascal,

Am Mi., 6. Feb. 2019 um 16:36 Uhr schrieb Pascal Thubert (pthubert) <
[email-masked]>:

> Hello Martine
>
>
>
> Fragments follow a same path, but this is not a guarantee that they will
> not be mis-ordered. So whatever you do, it should not be immediate but done
> upon a time out because once the VRB is gone, packets are dropped. Note
> that if the first packet is delayed, then minimal-fragment is in trouble.
>

That was clear ;-). However, I'm not sure it necessarily is in trouble. At
least in our (classic) reassembly buffer implementation, enough of the
original fragments data is still there (to detect overlaps), so that a
refragmentation for the first x fragments is still possible, once the first
fragment arrives and the reassembly buffer entry can be transformed into a
VRB entry.

For fragment-recovery-01 there is text in 7.3 about cleaning the VRB,
> basically an ACK that indicates a reset of a complete reception (all 0 or
> all 1) triggers a short timer to destroy the VRB. This is done in case the
> ack is lost on the rest of the way back and the last flow is retried. There
> is also text at the end of section 6 that indicates that a reset by the
> sender may not have an rfrag-ack request bit set. In that case, the same
> operation as if the RFRAG ack was received applies. I could add a word on
> that.
>

Ok, but for the sake of comparison I also need the minimal approach.

> Pascal

Best regards,
Martine

>
>
> *From:* 6lo <[email-masked]> *On Behalf Of * Martine Lenders
> *Sent:* mercredi 6 février 2019 15:49
> *To:* [email-masked]
> *Subject:* [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB
> entries?
>
>
>
> Hi,
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Feb 2019 16:46:59 +0000

Hello Martine

That was clear ;-). However, I'm not sure it necessarily is in trouble. At least in our (classic) reassembly buffer implementation, enough of the original fragments data is still there (to detect overlaps), so that a refragmentation for the first x fragments is still possible, once the first fragment arrives and the reassembly buffer entry can be transformed into a VRB entry.

Well, then it’s hard to differentiate an early fragment from a late fragment, and there‘s possibly an additional risk of DoS attack compared to a packet where the IP header allows some checking.

Minimal makes intermediate nodes virtual endpoints.
So I expect that the best you can do is behave like an end point and clear your state when 1) you have forwarded a complete virtual datagram and 2) upon time out in case of an error.
If you recreate a VRB for a late packet then yes, I’d protect case 1) that with a small time out to cover that situation.

All the best,

Pascal

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 7 Feb 2019 11:58:03 +0100

Hi Martine,

On 2/6/2019 3:49 PM, Martine Lenders wrote:
> fragments and remove the VRB entry once I reach the datagram size, 
> however this does not account for possibly received duplicates (unless I 
> keep track of at least the intervals of all received fragments which of 
> course costs more memory).

If you receive a fragment having a fragment_tag which you've already 
seen and the fragment_tag is not associated with any entry in the VRB 
table, you can consider it as a duplicate or late-arriving fragment. 
Then, you can drop the received fragment safely.

Best,
Yatch

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Feb 2019 12:23:19 +0100

On Feb 7, 2019, at 11:58, Yasuyuki Tanaka <[email-masked]> wrote:
> 
> If you receive a fragment having a fragment_tag which you've already seen and the fragment_tag is not associated with any entry in the VRB table, you can consider it as a duplicate or late-arriving fragment. Then, you can drop the received fragment safely.

That means you need a second table of datagram_tag values “already seen and done” (obviously with a timeout, or maybe with some serial number logic).
Maybe not a bad optimization to handle trailing duplicates.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Feb 2019 12:24:56 +0100

> However, I'm unsure how I can determine when it is safe to remove a VRB entry at least for the minimal forwarding case (even for a successfully transmitted datagram). As far as I have seen not even…

We did not discuss this in the draft because it is somewhat equivalent to timing out real reassembly buffers (RRBs? :-).  But maybe the strategy can be tweaked for VRB, so that is not a bad question at all.

Grüße, Carsten

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 7 Feb 2019 12:36:23 +0100

Hi Carsten,
> Maybe not a bad optimization to handle trailing duplicates.

Yes, some mechanism to track datagram_tag is needed, which is implied by 
draft-ietf-6lo-minimal-fragment-00:

    [From Section 1, draft-ietf-6lo-minimal-fragment-00]
    Node B's typical behavior, per [RFC4944], is as follows.  Upon
    receiving a fragment from node A with a datagram_tag previously
    unseen from node A, node B allocates a buffer large enough to hold
    the entire packet.

Since datagram_tag is expected to be incremented (by one) as RFC4944 
specifies, holding the last datagram_tag per peer may be enough, 
although this kind of thing could be "implementation-specific":

    [Section 5.3, RFC4944]
    datagram_tag:  The value of datagram_tag (datagram tag) SHALL be the
       same for all link fragments of a payload (e.g., IPv6) datagram.
       The sender SHALL increment datagram_tag for successive, fragmented
       datagrams.  The incremented value of datagram_tag SHALL wrap from
       65535 back to zero.  This field is 16 bits long, and its initial
       value is not defined.

Best,
Yatch

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Feb 2019 12:41:32 +0100

On Feb 7, 2019, at 12:36, Yasuyuki Tanaka <[email-masked]> wrote:
> 
> Since datagram_tag is expected to be incremented (by one) as RFC4944 specifies, holding the last datagram_tag per peer may be enough, although this kind of thing could be "implementation-specific":

Right.  We don’t want to blackhole datagrams after a reboot, and we want to allow the sending implementation to forget their neighbor state (which might include that counter, if it is not global) after a while.  So I think some form of timeout may be needed.

Grüße, Carsten