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

[richard <richard@pacdat.net>]

On Wed, 2011-03-16 at 23:22 +0100, Richard Scheffenegger wrote:
> 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.
> 
I don't think it is heretical - I think it is pragmatic.

I see the problem as being 2 parts:

now - with current hardware in place and whatever (broken) AQM and ECN
might be available to be turned on

future - products not out of development yet, software updates, etc.

> 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.
> 

In other words - let the normal TCP "lose a few packets and fix the
window size" mechanism actually do its work and/or turn on ECN and get
the rest of the world to at least not drop it due to mis-configured
stuff, because that technology is in place now.

This is a "now" thing, achieved by publicity, cajoling, shaming,
education, etc. to the network engineers and management as well as the
general public - "Anything is better than nothing" so turn on your QOS
and set your bandrate limiter and turn on ECN and get some sort of AQM
working and oh, by the way, for this situation this, this, this and that
are suggestions"

> 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...
> 

The stuff for the future involves getting to the designers and getting
them to understand the situation they're putting the rest of the net in
while they play their pissing games with marketing (is there any other
reason for 4 GB of buffer in any switch?), etc. That and getting the
basic research done, measurement facilities in place, and long-term
methodologies to really fix the problem "forever".

So no, it isn't heretical :)

richard

> 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 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
-- 
Richard C. Pitt                 Pacific Data Capture
rcpitt@pacdat.net               604-644-9265
http://digital-rag.com          www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333  57F0 4F18 AF98 9F59 DD73