PAPADIMITRIOU Dimitri allegedly wrote on 07/31/2009 03:45 EDT:
- 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.
We need to sort out priorities and milestones. Short term goals should
just be about the endpoints acting on their own. In that case you are
right. However, there is lots of useful speculation about future work
in which endpoints and routers (or other infrastructure services) could
work together so that endpoints could take advantage of more path diversity.
Note: The term "path" is from this perspective a bit confusing i.e.
inverse multiplexed TCP or multi component TCP would probably better
suite.
A path is a way of getting from one endpoint to another. Subflows
follow potentially different paths. The collection of paths taken by
all subflows might need a name.
- 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).
WG short term: if an endpoint has multiple interfaces, it can direct
traffic to those on which it sees less congestion (taking policy, cost,
etc. into account). That will certainly avoid congestion as experienced
by the endpoint, which will certainly do at least as well as current TCP
at lowering congestion in the network. In the future we can explore
interactions between network TE and endpoint MPTCP.
Are you concerned about synchronization and oscillations?
- 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.
The endpoint (currently) doesn't know what is going on in routing.
MPTCP will use potentially all paths that work. If routing breaks MPTCP
will stop using broken paths, and when FRR heals those paths MPTCP will
use them again. If they are on the same time scale, then on the
broken/healed path you may get packet behavior similar to current TCP,
except that retransmits can take place on other paths during the outage.
Scott
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf