[net2-wg] Flush Requirements

[Rodrigo Fonseca]

Hi,

here are the most important requirements that Flush has on the LL (or
on some other set of components sitting below it).

I added all of the currently sent requirements to the group wiki, at

http://tinyos.stanford.edu:8000/Net2WG/Topics/LinkLayerRequirements

Please add new ones there and you can freely edit it.

Cheers,
Rodrigo


== Flush (Fast bulk data transfer) - Rodrigo ==
 * Brief description

 . Flush is the next generation of Straw, a protocol that aims at
maximizing the throughput of bulk data transfer, one flow at a time in
the network, enforcing 100% reliability. There are two parts to Flush:
one that pipelines packets over multiple hops ideally as fast as
possible, while trying to minimize self-interference in the path
(among adjacent packets), and one that does a transport layer
functionality, by running an end-to-end protocol that enforces that
100% of the data is correctly received. The end-to-end mechanisms
often involve multiple rounds of transfers to get the missing data. We
assume that the Link Layer provides queueing of some sort (which could
also be a pool, there is no strict requirement on the ordering). Flush
imposes some interesting requirements on the one hop layer.
 * ''Timing information feedback'': Flush requires that the LL provide
timing feedback on all packets: how long did the packet take after it
was dequeued for sending, including all of the LL retransmissions and
the MAC layer delays?
 * ''Late stamping'' of this timing information in the packet: after
the packet leaves the queue, and before it is sent directly to the
radio, Flush stamps it with the average of the delay of the previous
packets. This average is computed from the number collected above.
This is also not the same as post arbitration time, but would probably
benefit from similar mechanisms.
 * ''Rate Limiting'': very important feature for the pipelining to
work in a stable fashion is the ability to tell the link layer to not
send faster than a given rate (or, equivalently, not to send with an
inter-packet interval smaller than some value). This is done in Flush
at each hop, and not only at the source. Although and optimization, it
provides for much less bursty rates. What happens in the common case
when there's no rate limiting is that nodes drain the queues too fast,
making the overall throughput suffer.
 * ''Snooping of Traffic'': Flush needs rate information to flow in
the reverse path in order to obtain a good throughput. This is done by
embedding in the packets that go forward information destined to the
previous hop(s). These nodes snoop the traffic and adjust their rates
accordingly. If snooping is not provided, at least broadcast is
required. Since all nodes are part of a single path here, it is
reasonable to say that they are all awake.
These are the most important features.