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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf