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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf