[Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?
Richard Scheffenegger
rscheff at gmx.at
Wed Mar 16 15:22:24 PDT 2011
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 at 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 at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
More information about the Bloat
mailing list