On Fri, 4 Oct 2002, Petri Helenius wrote:
Vendor C sells packet memory up to 256M each way for a line card. Whether this makes any sense depends obviously on your interfaces.
Hm, even at 10 Gbps 256M would add up to a delay of something like 200 ms. I doubt this is something customers like. Don't forget TCP can handle either a long round trip time or packet loss relatively well, but not both at the same time. So if you're doing that much buffering you should make absolutely sure it's enough to get rid of tail drops or TCP performance will be extremely poor.
Theoretically it makes sense to be able to accommodate the number of flows you´re carrying times the window size advertised by TCP.
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. 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. 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). Iljitsch