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