[e2e] Once again "Dynamik Congestion Control to Improve Performacne of TCP Split-Connections over Satellite Links"

[Detlef Bosau]

Detlef Bosau wrote:

Once upon a time, I wrote:

> Just another question. I´m trying to understand a paper "Dynamik 
> Congestion Control to Improve Performacne of TCP Split-Connections over 
> Satellite Links" by Lijuan Wu, Fei Peng, Victor C.M. Leung, appeared in 
> Proc. ICCCN 2004, and I´m about to throw the towel. I somehow feel, it´s 
> related work for me, but after a couple of days I still do not see, 
> which problem is solved in this paper.
...
> 
> Refering to the aforementioned paper, a satellite link is "lossy".
> 
> Now, the authors propose a splitting/spoofing architecture:
> 
> 
> SND----netw.cloud----P1---satellite link----P2-----netw.cloud----RCV
> 
> P1, P2: "Proxies".
> 
> Let´s assume splitt connection gateways (I-TCP, Bakre/Badrinath, 1994 or 
> 1995).

I think, I´ve seen the problem. Normally, I would not bother this list 
with critical remarks on each paper I read. Surely, this would be 
annoying and distracting. (However, there are so funny papers around. Is 
there a list for howlers, where one could discuss the best ones?)

However, this is an important one, because I guess, the authors here are 
not the only victims of a NS2 pecularity, I myself made this mistake 
more than once:

The authors claim a congestion problem at the "MAC queue" from P1 to the 
satellite link.

It´s the good old "source congestion", which is met in NS2 because the 
NS2 implementation does not distinguish TCP senders from routers and 
thus does not implement the "backpressure to wire speed", which should 
be part of any well done socket implementation.

In NS2, a TCP sender enqueues a packet at the link and afterwards 
continues its work.

Normally, this does not result in problems. In NS2, queue lenghts are 
default 20 packets, as well as AWND. Thus, in startup phase, the "sender 
queue" may fill up a little until the flow is in congestion avoidance 
phase and the packet intervalls equalize.

However, in special cases, this can be a) a pitfall and b) an 
_important_ difference to reality.

Please correct me, if I´m wrong. But at the moment, I guess, the authors 
solve a self made problem here, which results from a programming 
simplification in NS2.

Again: This simplification is justified in most cases and implementing 
backpressure to wirespeed in the NS2 is a bit tricky. However, the 
authors have found one of the rare cases, where "NS2 source congestion" 
is a problem ;-)

And of course, "backpressure through proxies" _is_ a problem as far as I 
can see. (I know that some people disagree here.)
But to my understanding, the paper mentioned above does not tackle this 
issue. (However, it is really difficult to put this in a "related work" 
section in a paper. Ignoring it is wrong - a proper discussion is nearly 
impossible....)

Detlef Bosau


-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937