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 >-----Original Message----- >From: Richard Kelsey [mailto:[email protected]] >Sent: mercredi 24 juin 2009 22:19 >To: Pascal Thubert (pthubert) >Cc: [email protected] >Subject: piggybacked fragment ACKs > >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
