[Iccrg] improvement of tcp slow start
mallman at icir.org
Fri Apr 6 17:36:16 BST 2007
I have read this thread and have a few comments ...
> But I think this behaviour is to slow, so that most of the connection
> can not use the maximum speed.
> So I thought about improvements. If you change the std behaviour
> (tp->snd_cwnd++;) with multiply by 3(tp->snd_cwnd+=2) you get this
> I also tried to replace (tp->snd_cwnd++;) with something like
> (tp->snd_cwnd *= 2) but I think this is to aggressive and should not
> be used:
> The slowstart algorithm is from a time, where 56k modems where state
> of the art, but it is too less aggressive for todays networks. So I
> suggest to replace it with +=2 or +=3.
(1) It is easy to make TCP's algorithms more aggressive and look at the
positives and say "we should take that path". But, you also have to
look at the negatives and your simulation really does nothing except
plot an exponential function with difference increase factors. It
is interesting to me in the above that you found a place that is
"to[o] aggressive". Why should we not use *= 2, but we should use
+= 2. If you want to suggest a change in the factor then you need
to actually figure out the pros and cons.
E.g., the RTO estimator might get hosed if you build a queue faster
than expected and so end up needlessly retransmitting and hosing
E.g., you have changed the worst possible case from sending twice as
fast as the capacity can absorb to sending three or four times as
fast. What are the implications of this (for the connection using
the change and the for competing traffic)?
(2) This is sort of an interesting note to me because a very long time
ago I needed some 2 page paper for a class on TCP and given my
procrastination I had about half an hour to do it. So, I first
suggested that we triple instead of double every RTT. The bigger
point I then tried to make was "why is 2 magic?". I don't
necessarily think 2 is magic. We would need to be careful about
changing it and making sure that change meshed well with the rest of
TCP's algorithms and that we understood the implications. It seems
to me that you are simply proposing an out-of-the-air new magic
number. We shouldn't do that.
(3) There are plenty of suggestions for how to increase the speed of
slow start and to try to grok when it is ending. (From TCB sharing
to swift start to the congestion manager to quick start to Hoe's
work on figuring out when to end to ...) Perhaps we should not
bother with this parameter tweaking business, but pick a
fundamentally better way to go.
Or, perhaps we should get rid of the parameter---and the algorithm.
The ridiculously stupid end of this spectrum is that initially you
can send as fast as you want:
Dan Liu, Mark Allman, Shudong Jin, Limin Wang. Congestion
Control Without a Startup Phase. Protocols for Fast, Long
Distance Networks (PFLDnet) Workshop, February 2007.
Sometimes it is OK. Sometimes not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070406/9d604b22/attachment.bin
More information about the Iccrg