Congestion-management subtleties

Posted Jan 26, 2011 2:05 UTC (Wed) by jthill (guest, #56558) [Link]

Yeah, that's the idea, only IP-aware, not so unselective. As I said, I think this scheme starts running out of steam as you get towards the core. Cisco's saying theirs starts there, where the routers are already too busy to think. If more than a few simple address ranges were included in this scheme's backpressure notifications I think it'd start getting ugly. For e.g. intranet border routers it occurs to me greenlight ranges (send me what you want for these guys, you hang on to traffic for anyplace else) would be simpler.

Fwliw, seems to me from reading his links that gmaxwell has it right about the seeming contradiction between the results Gettys and Villamizar/Song get - if I recall prices then, the idea of grossly overprovisioning buffers would have seemed insane in 1994. Plus the market was more technical, so there'd be little reason for the earlier study to examine it.

Some things I like about this notion (I am, of course, completely objective on the subject) are that

• Unlike Cisco's BCN, the sender can still forward e.g. network control packets (in addition to packets destined for outbound uncongested links, because it knows what those are).
• Like Cisco's scheme it's incremental. If the congestion is local only, i.e. if the aggregate buffering in the route back to the source is sufficient, the sending TCPs never see it at all—and when they do hear of it, they hear via backpressure from their local router:
  • The pipe is never unnecessarily drained
  • they know why they're not getting ACKs if the jam lasts, they don't have to retransmit
  • and they can prioritize what to send when polled using every bit of local state

There's more, they're all even more obvious than these.