nanog mailing list archives
Re: UUNET Routing issues
From: "Petri Helenius" <pete () he iki fi>
Date: Fri, 4 Oct 2002 22:28:01 +0300
Curious. Then the objective of buffering would be to absorb the entire window for each TCP flow. Is this a good thing to do? That will only add more delay, so TCP will use larger windows and you need more buffering... Kind of an arms race between the routers and the hosts to see which can buffer more data.
You usually end up with 64k window with modern systems anyway. Hardly anything uses window scaling bits actively. Obviously by dropping select packets you can keep the window at a more moderate size. Doing this effectively would require the box to regocnize flows which is not feasible at high speeds. (unless you´re caspian sales person :-)
Also, well-behaved TCP implementations shouldn't send a full window worth of data back to back. The only way I can see this happening is when the application at the receiving end stalls and then absorbs all the data buffered by the receiving TCP at once. But then the sending TCP should initiate the congestion avoidance algorithm, IMO.
I didn´t want to imply that the packets would be back to back in the queue but if you have a relatively short path with real latency in order of few tens of milliseconds and introduce extra 1000ms to the path, you have a full window of packets on the same queue. They will not be adjacent to each other but they would be sitting in the same packet memory.
Under normal circumstances, the full window worth of data will be spread out over the entire path with no more than two packets arriving back to back at routers along the way (unless one session monopolizes a link).
This discussion started as a discussion of non-normal circumstances. Not sure if the consensus is that congestion is non-normal. It´s very complicated to agree on metrics that define a "normal" network. Most people consider some packet loss normal and some jitter normal. Some people even accept their DNS to be offline for 60 seconds every hour for a "reload" as normal. Pete
Current thread:
- Re: UUNET is not the Internet (and neither is AOL), (continued)
- Re: UUNET is not the Internet (and neither is AOL) Tim Thorne (Oct 05)
- Re: UUNET is not the Internet (and neither is AOL) Sean Donelan (Oct 05)
- Message not available
- Re: UUNET is not the Internet (and neither is AOL) Vicky O. Mair (Oct 06)
- Re: UUNET is not the Internet (and neither is AOL) alex (Oct 07)
- Re: UUNET is not the Internet (and neither is AOL) Sean Donelan (Oct 07)
- RE: UUNET is not the Internet (and neither is AOL) Cleve Mickles (Oct 07)
- Re: UUNET is not the Internet (and neither is AOL) Jared Mauch (Oct 07)
- RE: UUNET is not the Internet (and neither is AOL) Ryan Fox (Oct 07)
- Re: UUNET is not the Internet (and neither is AOL) Dave Israel (Oct 07)
- Re: UUNET is not the Internet (and neither is AOL) Petri Helenius (Oct 07)
- Re: UUNET Routing issues Petri Helenius (Oct 04)
- Re: UUNET Routing issues Valdis . Kletnieks (Oct 04)
- Re: UUNET Routing issues Petri Helenius (Oct 04)
- Re: UUNET Routing issues Iljitsch van Beijnum (Oct 04)
- Re: UUNET Routing issues Rafi Sadowsky (Oct 05)
- Re: UUNET Routing issues Iljitsch van Beijnum (Oct 05)
- Re: UUNET Routing issues Marshall Eubanks (Oct 05)
- Re: UUNET Routing issues Petri Helenius (Oct 05)
- Re: UUNET Routing issues Stephen Sprunk (Oct 03)
- Re: UUNET Routing issues Scott Granados (Oct 06)