![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
I fully agree. TCP window advertisements are supposed to show how much buffer space the receiver has available. The receiver should not have to artificially limit its window because of network considerations -- that's the function of congestion control on the transmitting end. One problem we do have with the existing TCP congestion control mechanism is that the sender will increase its congestion window all the way up to the offered window as long as no packets are lost, even if all those extra packets just pile up in a queue at the bottleneck router. Various ad-hoc methods involving real-time bandwidth/delay measurements have been tried to solve this problem, but they don't seem to work really well because of measurement noise (competing traffic, route changes, etc). Signalling congestion by deliberately dropping packets when buffer space is still available has always bothered me. There has to be a better way. Besides, I'm of the opinion that there's just no alternative to having lots and lots of router buffering, especially on high speed/long delay links. If a TCP sends a packet into a bottlenecked path with generous link buffering, the worst that happens is that the packet waits in the queue for awhile. The link continues to pass traffic at full capacity. But if TCP timidly shrinks its congestion window to avoid packet drops in memory-starved routers, that increases the chance of the link going idle even when the TCPs have traffic to send. Idle link time is gone forever. Explicit congestion notification would help considerably. This doesn't necessarily require the definition of new bits in the IP and TCP headers; you can actually do quite a lot with the oft-maligned ICMP Source Quench message. I've found it quite effective in the common case of a host on a private leaf Ethernet sending data through a dialup router to the outside world. It certainly reacts more quickly than a mechanism that requires a far-end turnaround of the congestion bit. Phil
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.