>From the conex- mailing list:
further arguments against handling congestions by the hosts. I would assume that it is in the interest of some particular ISP that its routers can cope with congestion and that they would like solutions which do not depend on wether the majority of host will be equipped with MPTCP and similar concepts. This means they would like to depend on their own. I think it is more than obvious where to put congestion handling intelligence. Heiner -----Ursprüngliche Mitteilung----- Von: Mikael Abrahamsson <[email protected]> An: [email protected] Verschickt: Do., 12. Aug. 2010, 12:27 Thema: [conex] comments on draft-conex-mechanism-00.txt Hi. Just subscribed to the list (missed the start of this WG), sorry, can't reply to another thread because I don't have the original email. So, I've started reading draft-conex-mechanism-00.txt. I object to the writing: "For an operator facing congestion caused by other operators' networks, building out its own capacity is unlikely to solve the congestion problem." If traffic isn't DDoS or caused my malware, it's traffic the customer wanted. The traffic isn't caused by "other operators' networks", it's caused by customer interaction with customers on other ISPs networks, thus something the customer wants to do. The above writing perhaps has place in a text sent so the regulator by a an entity who wants to justify its actions and avoid regulation or repercussions, but I don't think it is appropriate in an IETF document. Oh well, over to the more technical part: 7. Use cases. I don't agree on the three approcahes. Point 1 and 3 means a router has to handle flows, this doesn't scale. Point 2 involves the "router" being congested. Perhaps what's meant is that a link connected to the router is congested egress (because that's where the queue will be)? As I've said before, we're going more and more to simple cheap devices with small buffers and forwarding tables that are really quick (TCAM or alike). These devices are not flow aware and they don't really do RED either (it's pointless considering their small buffers). It's an important consideration for this wg how this should be handled. I don't see any discussion about it... 7.1. Here it's said that flow-aware equipment is expensive, that's good. It's important to remember. Again, there is talk about "congested routers" which I think is the wrong term. 8. Here is a good point about congestion not being a secret. The problem is that the IP stack knows about it, but the user does not (apart from deducing this from what how the application is behaving ("slow")). As some has seen from my postings on other IETG lists, I think there should be user insight into performance (metrics how the IP stack is behaving so this can be exposed to the user). Could this be part of the work done in this WG, actually exposing the CONEX performance data to the user? I think this is an important point. I don't really object to the work being done, it's just that since ECN hasn't caught on in real life (it's in most end user OSes nowadays, I don't know many network devices which are ECN aware) I don't really see how the new propsals are actually going to be deployed? Are the hardware guys involved in the discussions so we know how hard things are to implement? -- Mikael Abrahamsson email: [email protected]
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
