I see value in working on a "linked" congestion control scheme (work consisting in architecting and determining how efficient such scheme would be compared to current practice/congestion control schemes). I have a couple of comments/concerns though: - The BoF presentation considers that the TCP end-points controls routing of the traffic along a certain path in the network but routing information does not reach the end-points. So for what it concerns routing of the traffic, per TCP connection, there is no difference compared to the current situation (the network is not aware that two connections entering the network belong to the same "set"). This assumption is to be revisited because the "possible" paths towards (set of destinations) will be as provided by the routing system and means for triggering and enforcing diversity inside network is not achievable without additional mechanism (at the "networking layer" level). Note: The term "path" is from this perspective a bit confusing i.e. inverse multiplexed TCP or multi component TCP would probably better suite. - The BoF presentation considers that controlling onto which (sub-)connection the source puts traffic leads to offload the network from performing traffic engineering. Thus, I do not see how this would lead to a situation where the network would be free from any traffic engineering ? (I would even say the contrary, this would lead us back to the hyper-aggregation problem). - On the proposed scheme itself, if the end-points assumes that sub-connections (say between IP Address 1 and 2) can not be re-established after detecting their failures, the degraded state would remain permanent since the connection between Address 1 and 2 would not be re-established. So, it may be that some of the decisions taken by the end-points become detrimental. At this stage, it is not clear how to prevent such situation would happen. Note: also that some of the RTT numbers provided in the presentations are within recovery times achievable using fast re-routing schemes. Thanks, -dimitri. > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Christian Vogt > Sent: Wednesday, July 29, 2009 10:59 PM > To: IETF Discussion Mailing List > Cc: Multipath TCP Mailing List > Subject: On Thursday's Multipath TCP BOF > > Dear all - > > Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I > would like to express my support for this effort by email. > > Multipath TCP promises to enable an attractive set of new features -- > ranging from automatic fail-over, to load-balancing, to mobility > support. Even though there are, of course, important challenges to be > surmounted, early analyses indicate the feasibility of the concept as > such. And the strong academic background and support from key IETF > folks ensures that people with clue and sufficient time will > work on it. > > Therefore, personally, I believe this BOF should be given a thumbs-up > for working group establishment. > > - Christian > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf