ABC is strictly enforcing byte based CWND growth now.
All the details are in RFC3465.
That certainly is an odd looking trace. There doesn't happen to be a
system call trace to go along with it does there? It looks like it goes
along like this:
13:23:33.458806 IP l.5877 > l.12823: P 29110:29129(19) ack 52355 win 12374
13:23:33.459033 IP l.12823 > l.5877: P 52355:52359(4) ack 29129 win 9148
13:23:33.459113 IP l.12823 > l.5877: P 52359:52363(4) ack 29129 win 9148
13:23:33.497730 IP l.5877 > l.12823: . ack 52363 win 12374
13:23:33.497922 IP l.12823 > l.5877: P 52363:52374(11) ack 29129 win 9148
13:23:33.497971 IP l.5877 > l.12823: . ack 52374 win 12374
13:23:33.498205 IP l.5877 > l.12823: P 29129:29148(19) ack 52374 win 12374
13:23:33.498376 IP l.12823 > l.5877: P 52374:52378(4) ack 29148 win 9148
13:23:33.498454 IP l.12823 > l.5877: P 52378:52382(4) ack 29148 win 9148
13:23:33.537755 IP l.5877 > l.12823: . ack 52382 win 12374
13:23:33.538177 IP l.12823 > l.5877: P 52382:52386(4) ack 29148 win 9148
13:23:33.540439 IP l.5877 > l.12823: . ack 52386 win 12374
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.
If that is true, and if the number of allowable outstanding segments
were based on say the byte value of the cwnd divided by the MSS I could
see where something doing small sends could indeed take a very long time.
Before, one ACK added one MSS and so one segment right? That still
"covered" the small packet case when cwnd was kept in units of bytes.
I thought that the principle behind VJ congestion control was
conservation of packets. An ACK arrived telling you that your previous
packet had left the network, so now you can sent two packets.
I can see where ABC doesn't want the exchange of small packets to then
allow a burst of big segments, but it seems that maybe the 'cwnd' has to
be both bytes and segments now and segments not just cwndbytes/MSS? The
small packet sender could then properly slow-start to some number of
small segments without then being able to suddenly inject a burst of
that many large segments.
FWIW I asked one of the ProCurve guys how their queues were limited, and
it was based on packet count, not byte count
rick jones
-
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
