[Iccrg] improvement of tcp slow start

[Mark Allman]

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
    performance.

    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.
        http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf

    Sometimes it is OK.  Sometimes not.

allman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070406/9d604b22/attachment.bin