[Iccrg] improvement of tcp slow start

[Lachlan Andrew]

Greetigns Stefan,

On 17/03/07, Stefan Hirschmann <krasnoj at gmx.at> wrote:
> In the average scenarios, it can happen, that current +=1 makes a bigger
> overshoot than +=2, e.g. with 8 KByte/sec. You have 1,2,4,8,16
> overshoot=16-8=8. But with +=2 you have 1,3,9, overshoot=9-8=1.

No.  The sequence 1, 2, 4, ... only applies once per RTT, but the
window increments are every packet.  That quantisation makes all the
difference in your example.

Both will cause loss   as soon as   the cwnd exceeds the BDP + buffer.
 Both will take one RTT to respond.  The one which triples the window
each RTT will have a cwnd of 3*(BDP+buffer), and the one which doubles
the window each RTT will have 2*(BDP+buffer).  This doesn't depend on
the capacity or the link, or the buffer size.

>  > [...] see the recent discussion on the end2end-interest list [...]
> I didn't found this discussion. I looked for march and february. Can you
> tell me the topic, because I would like to read it?

It started as "Are we doing sliding window in the Internet?"

> > What would be more useful would be something which can detect when
> > slow-start is nearing its end -- like measuring queueing delay or some
> > property of the RTT-level burstiness -- so that we can start
> > aggressively but back off when we're nearing the end.
> This idea sounds interesting.
> But what is the best way dealing with changing routes, that can also
> change the RTT (or wireless connection with the resend of broken packets)?

You're right that routing changes are important, but if slow start is
fast enough then routing changes during slow start should not be
common enough to optimise for them.  Of course there should be some
"failsafe" in case they do occur.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603