Subject: [6lowpan] piggybacked fragment ACKs

From: Richard Kelsey <[email-masked]>
Date: Wed, 24 Jun 2009 16:19:11 -0400

Pascal,

In the past I have found it very useful to be able to
piggyback ACKs on other traffic.  From reading RFC4944 and
draft-thubert-6lowpan-simple-fragment-recovery-05 it looks
like there should be no problem prepending an RFRAG-ACK
header at the beginning of a LoWPAN datagram, as RFC4944
does with various other headers.  On the other hand, I can't
find anything that explictly allows this.  Do you see any
difficulty with piggybacking RFRAG-ACKs on other packets?

                               -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Jun 2009 22:45:10 +0200

> On the other hand, I can't
> find anything that explictly allows this.

So it's not allowed in the current text.
I agree it would be easy to add.

> Do you see any

That would mean my proposal to compress FRACKs by simply not sending  
trailing zero bytes would not work.
Solution:
1) adopt another one of Pascal's recent proposals for FRACK  
compression (A/B/B-reverse)
2) Simply don't compress the 32-bit field in the piggy-back case.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Jun 2009 08:36:54 +0200

Hi:

If we can get some rough consensus in this list I'll be happy to update
the draft.
Else, maybe we can ask the group in Stockholm?

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:[email-masked]]
>Sent: mercredi 24 juin 2009 22:45
>To: Richard Kelsey
>Cc: Pascal Thubert (pthubert); [email-masked]
>Subject: Re: [6lowpan] piggybacked fragment ACKs
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Jun 2009 08:44:20 +0200

Hi Richard:

I fully agree with Carsten; Also: 

FRACK might be used as a pacing mechanism, to limit the number of
outstanding fragments. When we get there, we might want to send a lot
more FRACKs than we do today, in which case piggybacking could be
useful, as long as there is reverse traffic that can be used for that
purpose.

An example of that is a slow firmware upgrade. Firmware chunks are
fragmented towards a device. The device piggy backs the FRACKs with the
sensor data. An outstanding window protects the network when many
devices are upgraded in parallel.

Note: I would not delay (too much?) the FRACK just to be able to piggy
back.

Pascal

>From: Richard Kelsey [mailto:[email-masked]]
>Sent: mercredi 24 juin 2009 22:19
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]
>Subject: piggybacked fragment ACKs
>
>Pascal,
>

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 25 Jun 2009 10:36:54 -0400

From: Carsten Bormann <[email-masked]>
   Date: Wed, 24 Jun 2009 22:45:10 +0200

Piggybacked FRACKs was the only reason I thought of for why
it would be worth compressing FRACKs, which is what started
me looking to see if doing so was allowed.  That being said,
even with piggybacked FRACKs I still don't think compessing
FRACKs is worth the added complexity.

                                 -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 25 Jun 2009 10:42:53 -0400

Date: Thu, 25 Jun 2009 08:44:20 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

   Note: I would not delay (too much?) the FRACK just to be able to
   piggy back.

The use case I care about is when the fragmented message is
a data query that generates an immediate response.
Putting the FRACK in with the response doesn't add any
delay.
                              -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Jun 2009 16:54:44 +0200

I thought so but then, you need to wait for the ack back to piggy back. 
6LoWPAN sublayer cannot know that such a thing is expected.
This is why I proposed an alternate use case while suggesting -for you
case- not to wait too long. 

Pascal

>Sent: jeudi 25 juin 2009 16:43
>Subject: Re: piggybacked fragment ACKs
>