[Cerowrt-devel] happy 4th!

[Mikael Abrahamsson]

On Thu, 4 Jul 2013, Michael Richardson wrote:

> huh?  The end points might need more buffers to receive more packets (some of
> which might be out of order), but the intermediate routers need nothing.
> None of the bufferbloat stuff reduces the receive buffers of an end-point.

I never talked about the end-points receive buffers. I was talking about 
intermediate routers buffering. With long-latency links, TCP traditionally 
sends packets at fairly big bursts sent at wirespeed of the end system, 
and when this burst arrives at a router doing speed conversion 
(1gige->1megabit/s WAN link), it will need to buffer some of this burst. 
This is why buffers are large on routers, because of this traditional 
thinking that TCP works best when routers in between never drops packets.

> So, who is saying this to you, and what exactly do they think 
> bufferbloat is about?

They say if you reduce the buffer size in routers, TCP performance on long 
latency paths will suffer due to packet loss and long recovery times due 
to the end-to-end high latency.

Traditional thinking (I've had this quoted to me by several old-timers who 
have been involved in core router design since the 90ties) is that you 
need buffers who can accept 2*RTT amount of packets at the speed you're 
trying to send.

So if we want to reduce the buffers, we need to prove that TCP goodput on 
a 200ms link doesn't suffer because there are now less buffers.

So my suggestion is the following:

When doing the tests, set up the following:

[host1] - (GE/FE/E) - [fq_codel router] - [100ms adding latency router] (GE) [host2]

The link between CODEL-router and the router adding latency should be 1/10 
and 1/100 of the [host1] - [CODEL-router] link speed.

If it can be shown that fq_codel keeps the goodput performance the same as 
FIFO with large buffers, then we hopefully could answer people with the 
concerns I mentioned before.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se