Subject: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

From: Martine Lenders <[email-masked]>
Date: Tue, 1 Oct 2019 16:31:05 +0200

Hi,

draft-ietf-6lo-fragment-recovery states in section 6.3

[the] might need to abort the process of a fragmented packet for internal
> reasons, for instance if it […] considers that this packet is already fully
> reassembled and passed to the upper layer. In that case, the receiver
> SHOULD indicate so to the sender with a NULL bitmap in a RFRAG
> Acknowledgment.

The given example seems to me the perfect instance to set a FULL bitmap
instead. There is no other instance were a FULL bitmap is specified to be
sent, except for the case that the datagram incidentally fills out the
whole value space of the sequence number field.

Or am I missing something?

Kind regards,
Martine

---

From: Martine Lenders <[email-masked]>
Date: Mon, 21 Oct 2019 16:34:43 +0200

Hi,

sadly, I did not receive an answer for this yet.

Best regards,
Martine

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Oct 2019 15:29:29 +0000

Sorry I missed that Martine!

The ALL 1s was already sent when the last fragment was received. This text happens later.

It is supposed to have been processed along the way back. The receiving end node maintains a state for a “short” time after the message processing to absorb packets that may still be in flight. During that “short” time it is capable to recognize redundant packets and drop them as opposed to create a new state and expect the full fragment. For legitimate packets still in flight the good thing would be to stay silent. If the Ack with a FULL (All 1s) bitmap was lost then sending it again would be OK as you point out.

But there might also be error conditions, like a weird situation that the FULL bitmap did not fix on its way back where the sender keeps sending. If the FULL bitmap failed then retrying it may fail again. The reset is a clearer indication to drop everything regardless and move to the next.

Works? Should we massage text?

All the best

Pascal

Am Di., 1. Okt. 2019 um 16:31 Uhr schrieb Martine Lenders <[email-masked]<mailto:[email-masked]>>:
Hi,

[the] might need to abort the process of a fragmented packet for internal reasons, for instance if it […] considers that this packet is already fully reassembled and passed to the upper layer. In that case, the receiver SHOULD indicate so to the sender with a NULL bitmap in a RFRAG Acknowledgment.

The given example seems to me the perfect instance to set a FULL bitmap instead. There is no other instance were a FULL bitmap is specified to be sent, except for the case that the datagram incidentally fills out the whole value space of the sequence number field.

Kind regards,
Martine

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Oct 2019 16:12:12 +0000

Hello Again

I reread the text and it appears that the receiver operation is too implicit. I suggest to add this in the last fragment processing:

    When all the fragments are received, the receiving endpoint reconstructs
    the packet, passes it to the upper layer, sends a RFRAG Acknowledgment on
    the reverse path with a FULL bitmap, and harms a short timer to absorb
    packets that are still in flight for that datagram without creating a new
    state and abort the communication if it keeps going.

Does that help?

Note that there’s room for an implementation to decide if it absorbs silently a few packets and for how long, and when it decides to reset the flow. The all 1 (to be renamed throughout to FULL)  does not help more than the reset.

Pascal

From: Pascal Thubert (pthubert)
Sent: lundi 21 octobre 2019 17:29
To: Martine Lenders <[email-masked]>; [email-masked]
Subject: RE: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

All the best

Pascal

Kind regards,
Martine

---

From: Martine Lenders <[email-masked]>
Date: Wed, 23 Oct 2019 14:28:56 +0200

Hi Pascal,

Am Mo., 21. Okt. 2019 um 18:14 Uhr schrieb Pascal Thubert (pthubert) <
[email-masked]>:

> Hello Again
>
>
>
> I reread the text and it appears that the receiver operation is too
> implicit. I suggest to add this in the last fragment processing:
>
>
>

If this goes somewhere in section 6, yes I think that makes it far more
understandable.

> Note that there’s room for an implementation to decide if it absorbs
> silently a few packets and for how long, and when it decides to reset the
> flow. The all 1 (to be renamed throughout to FULL)  does not help more than
> the reset.
>

By packets you mean fragments or reassembled datagrams. I don't really
understand what you mean by that.

Best regards,
Martine

>
>
> Pascal
>
>
>
>
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* lundi 21 octobre 2019 17:29
> *To:* Martine Lenders <[email-masked]>; [email-masked]
> *Subject:* RE: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap
> when datagram is complete?
>
>
>
> It is supposed to have been processed along the way back. The receiving
> end node maintains a state for a “short” time after the message processing
> to absorb packets that may still be in flight. During that “short” time it
> is capable to recognize redundant packets and drop them as opposed to
> create a new state and expect the full fragment. For legitimate packets
> still in flight the good thing would be to stay silent. If the Ack with a
> FULL (All 1s) bitmap was lost then sending it again would be OK as you
> point out.
>
>
>
> But there might also be error conditions, like a weird situation that the
> FULL bitmap did not fix on its way back where the sender keeps sending. If
> the FULL bitmap failed then retrying it may fail again. The reset is a
> clearer indication to drop everything regardless and move to the next.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 12:43:11 +0000

Hello Martine

I meant fragments. It can be expected that a few fragments are still in flight after everything is received because of end to end fragment retries or L2 ARQ. So the receiver must keep a state to drop them silently. But is it gets “too much “ of that it may be an error and the receiver should abort the flow.

That “too much” decision is left to implementation.

Regards,

Pascal

Le 23 oct. 2019 à 14:29, Martine Lenders <[email-masked]> a écrit :

Hi Pascal,

Am Mo., 21. Okt. 2019 um 18:14 Uhr schrieb Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Again

Does that help?

If this goes somewhere in section 6, yes I think that makes it far more understandable.

By packets you mean fragments or reassembled datagrams. I don't really understand what you mean by that.

Best regards,
Martine

Pascal

From: Pascal Thubert (pthubert)
Sent: lundi 21 octobre 2019 17:29
To: Martine Lenders <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

All the best

Pascal

Kind regards,
Martine

---

From: Martine Lenders <[email-masked]>
Date: Wed, 23 Oct 2019 14:45:38 +0200

Hi,

Am Mi., 23. Okt. 2019 um 14:43 Uhr schrieb Pascal Thubert (pthubert) <
[email-masked]>:

> Hello Martine
>
> I meant fragments. It can be expected that a few fragments are still in
> flight after everything is received because of end to end fragment retries
> or L2 ARQ. So the receiver must keep a state to drop them silently. But is
> it gets “too much “ of that it may be an error and the receiver should
> abort the flow.
>

Thank, now it is clearer!

Regards,
Martine

>> *Subject:* RE: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL
>> bitmap when datagram is complete?
>>
>>
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 12:51:42 +0000

Cool : )

I published 07, please see the diffs.

All the best;

Pascal

From: 6lo <[email-masked]> On Behalf Of Martine Lenders
Sent: mercredi 23 octobre 2019 14:46
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

Hi,

Am Mi., 23. Okt. 2019 um 14:43 Uhr schrieb Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Martine

Regards,
Martine

Regards,

Pascal

Le 23 oct. 2019 à 14:29, Martine Lenders <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Does that help?

Best regards,
Martine

Pascal

All the best

Pascal

Kind regards,
Martine

Subject: [6lo] I-D Action: draft-ietf-6lo-fragment-recovery-07.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 23 Oct 2019 12:48:11 +0000
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF.

        Title           : 6LoWPAN Selective Fragment Recovery
        Author          : Pascal Thubert
        Filename        : draft-ietf-6lo-fragment-recovery-07.txt
        Pages           : 26
        Date            : 2019-10-23

Abstract:
   This draft updates RFC 4944 with a simple protocol to recover
   individual fragments across a route-over mesh network, with a minimal
   flow control to protect the network against bloat.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-fragment-recovery-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Martine Lenders <[email-masked]>
Date: Wed, 23 Oct 2019 15:13:24 +0200

Hi Pascal,

Sorry, I noticed this in your original mail, but forgot to mention it, now
it is also in the draft:

> […] Acknowledgment on the reverse path with a FULL bitmap, and harms a
> short timer to absorb packets that are still in flight for that […]

Do you mean "arms a short timer"?

Best regards,
Martine

Am Mi., 23. Okt. 2019 um 14:52 Uhr schrieb Pascal Thubert (pthubert) <
[email-masked]>:

> *From:* 6lo <[email-masked]> *On Behalf Of *Martine Lenders
> *Sent:* mercredi 23 octobre 2019 14:46
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 13:51:06 +0000

Yup I’ll fix that typo at the next and will also replace packet by fragment as you indicated. I just failed to commit that this round, sorry for that!

Regards,

Pascal

Le 23 oct. 2019 à 15:14, Martine Lenders <[email-masked]> a écrit :

Hi Pascal,

Best regards,
Martine

Am Mi., 23. Okt. 2019 um 14:52 Uhr schrieb Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Cool : )

All the best;

Pascal

From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Martine Lenders
Sent: mercredi 23 octobre 2019 14:46
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

Hi,

Regards,
Martine

Regards,

Pascal

Hi Pascal,

Does that help?

Note that there’s room for an implementation to decide if it absorbs silently a few packets and for how long, and when it decides to reset the flow. The all 1 (to be renamed throughout to FULL)  does not help more than the reset..

Best regards,
Martine

Pascal

From: Pascal Thubert (pthubert)
Sent: lundi 21 octobre 2019 17:29
To: Martine Lenders <[email-masked]<mailto:m.lenders@fu-berlin..de>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitmap when datagram is complete?

All the best

Pascal

Kind regards,
Martine