Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?

["Richard Scheffenegger" <rscheff@gmx.at>]

Heretical question: Why must the congestion notification implemented as a 
(distributed) function of the network itself, and take the reaction of the 
end hosts into consideration. If the signaling would only indicate the local 
congestion state, but then move the reaction to that into the end hosts, i 
think the design would be much more simple.

If the network would let the (reactive) senders know the extent of the 
current congestion, the end hosts can use more smarts and react to it 
properly.

However, AQMs are designed with the standard TCP reaction in mind - half the 
sending rate at any indication of congestion within one RTT.

(See DCTCP, Conex for additional information).


Furthermore, I learned that a couple of 10G switch vendors are planning to 
have up to 4 GB of buffer RAM in their next generation of switches. So we 
are not talking about thousands of packets in the buffer, but of millions of 
packets (think of up to 400ms buffering if only a single 10G egress port is 
being loaded in such a switch). Compared to the base RTT of a 10G network (a 
few tens of microseconds, some vendors go even below a microsecond), this is 
even more extreme than the home router / DSLAM scenario...

Regards,
  Richard


----- Original Message ----- 
From: "Jonathan Morton" <chromatix99@gmail.com>

With that said, at 10GE speeds you are approaching a megapacket per second 
if jumbo frames are not a significant fraction of the traffic.  I think 
something like SFQ can be made to work at those speeds, but simply getting 
the data through the computer that fast is a fairly tough job.  So I agree 
that if the NIC can do it by itself, so much the better.

On the flip side, at a megapacket per second, a thousand-packet buffer 
empties in a millisecond.  That's less than a disk seek.

 - Jonathan

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat