[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
Hi,
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
delivered.
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?
Regards,
Kara
-------------- 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