[e2e] Do we need congestion control for unicast traffic with intra-session network coding

shun cai vitacaishun at gmail.com
Tue Mar 12 20:42:30 PDT 2013


    I am thinking of the congestion control problem for  MORE-like traffic
in Wireless Mesh networks, and get perplexed by some questions. I do
apprecitate for your kind help.

   1. MORE-like unicast  traffic uses multipath routing with intra-session
network coding, in which packets are randomly linearly encoded at both the
source and the intermediates nodes.  Specifically, Source s first divides
the original message into batches, each containing K packets of the same
length. It then generates and broadcasts random linearly combined packets
within the current batch. Intermediates buffer the overheard packets, and
then re-encode them before forwarding. Destination t recovers the original
batch by collecting sufficient number of encoded packets, and then sends
ACK to s so as to trigger the next batch until the whole message is

  2. Packets belong to current batch  should buffered at intermediate
nodes, does  the buffer here refer to the MAC queue or a cache at upper
layer (e.g. socket buffer, or  a cache in memory) .
     In my opinion,  the received belong to a current batch will occupy the
MAC queue  for  quite a long time before the whole batch is delivered to
the destionation, which causes  the  MAC queue overflow very easily.  So
the better way is to buffer thesed packets at upper layer, right ?

3. If the packets are buffered at upper layer,  the MORE traffic is less
likely to be the reason of the congestion at routers, right?  As the coded
packets is  generated and sent to MAC queue  only when the MAC is able to
transmit , at any time, there is at most one packet for each coded traffic
in the MAC queue.

3. If the conjecture in item 2 is true, do we need any congestion control
for MORE-like traffic?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130313/2a744901/attachment.html

More information about the end2end-interest mailing list