[e2e] How shall we deal with servers with different bandwidths and a common bottleneck to the client?

Detlef Bosau detlef.bosau at web.de
Sun Dec 24 14:52:56 PST 2006


Detlef Bosau wrote:
> I apologize if this is a stupid question.

I admit, it was a *very* stupid question :-)

Because my ASCII arts were terrible, I add a nam-screenshot here 
(hopefully, I´m allowed to send this mail in HTML):

NAM screenshot

Links:
0-2: 100 Mbit/s, 1 ms
1-2: 10 Mbit/s, 1 ms
2-3: 100 Mbit/s, 10 ms
3-4: 10 MBit/s, 1 ms

Sender: 0,1
Receiver: 4
>
>
> My feeling is that the flow server 1 - client should achieve more 
> throughput than the other. From what I see in a simulation, the ratio 
> in the secnario above is roughly 2:1. (I did this simulation this 
> evening, so admittedly there might be errors.)
>
> Is there a general opinion how the throughput ratio should be in a 
> scenario like this?


Obviously, my feeling is wrong. Perhaps, I should consider reality more 
than my feelings :-[

AIMD distributes  the *path capacity (i.e. "memory") *in equal shares.  
So, in case of two flows sharing a path, each flow is assigned an equal 
window. Hence, the rates should be equal as they depend on the window (= 
estimate of path capaciyt) and RTT. (Well known rule of thumb: rate = 
cwnd/RTT)

However, the scenario depicted above is an interesting one: Apparently, 
the sender at node 1 is paced "ideally" by the link 1-2. So, packets 
sent by node 0 are dropped at node 3 unuduly often.  In consequence, the 
flow from 0 to 4 hardly achieves any throughput whereas the flow from 1 
to 4 runs as if there was no competitor.

If the bandwdith 1-2 is changed a little bit, the bevaviour returns to 
the expected one.

I´m still not quite sure whether this behaviour matches reality or 
whether it is an NS2 artifact.

Detlef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20061224/3033e94c/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bild.png
Type: image/png
Size: 21858 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20061224/3033e94c/bild-0001.png


More information about the end2end-interest mailing list