On Fri, 10 Mar 2006 16:16:07 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:

> >>I would have thought that byte based growth of the CWND would have meant 
> >>that the ACK's above would have allowed more bytes to flow, yet more 
> >>bytes are not flowing.  That makes it seem like cwnd isn't strictly 
> >>bytes, but is also tracked in terms of number of outstanding segments.
> > 
> > 
> > Linux cwnd is in packets.
> 
> How is the ABC cwnd of bytes mapped to packets? Does it only go up by 
> one packet after an MSS has been ACKed then?
> 

/*
 * Linear increase during slow start
 */
void tcp_slow_start(struct tcp_sock *tp)
{
        if (sysctl_tcp_abc) {
                /* RFC3465: Slow Start
                 * TCP sender SHOULD increase cwnd by the number of
                 * previously unacknowledged bytes ACKed by each incoming
                 * acknowledgment, provided the increase is not more than L
                 */
                if (tp->bytes_acked < tp->mss_cache)
                        return;

                /* We MAY increase by 2 if discovered delayed ack */
                if (sysctl_tcp_abc > 1 && tp->bytes_acked > 2*tp->mss_cache) {
                        if (tp->snd_cwnd < tp->snd_cwnd_clamp)
                                tp->snd_cwnd++;
                }
        }
        tp->bytes_acked = 0;

        if (tp->snd_cwnd < tp->snd_cwnd_clamp)
                tp->snd_cwnd++;
}

> > Think of congestion window as measurement of the available sewer pipe.
> > If everyone thinks the congestion window is too large, then the sewer pipe
> > would back up and nothing would overflow.
> > 
> > Small packets are like a leaky faucet dripping, just because a drip goes
> > down the drain doesn't tell you much about the available pipe diameter.
> 
> I agree that if I can have five drips outstanding I should not be able 
> to then put five buckets out there, but should I have to exchange 
> another 1460 drips before I can have six drips outstanding?

The drips count for nothing as far as congestion is concerned when
we need to count toilet bowls (enough with this analogy)...

> 
> Admittedly, this specific application is a bad client for the case I'm 
> trying to make, but if it were properly putting messages to the 
> transport in one call, but trying to have five of them outstanding at a 
> time I get the impression it would be a very long time before it could 
> get all five outstanding.  I guess netperf TCP_RR with configured with 
> --enable-burst would be one way to check that.

The other problem this application has is that by the time it builds up
enough bytes acked to open the congestion window, it goes back to sleep for
a long enough time for the window to be restarted. 
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to