RE: [multipathtcp] On Thursday's Multipath TCP BOF

["PAPADIMITRIOU Dimitri" <[e-mail]>]

Scott:

> > - 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.

A path may be defined as the "trajectory" packet follows to reach the
destination (i.e., as determined by a sequence of hops traversed by the
packets). As there is no mechanism for TCP to enforce the path followed
by the packets in the network I do not see at all where the "longer"
term objective could actually lead. Techniques that consist in driving
the path followed by packets from the source to the destination
(source-routing) in connectionless datagrams networks requires either
signaling or encoding the "route" into the packet header. 

This said, as far as I read you answer we seem to be in agreement ditto
"Short term goals should just be about the endpoints acting on their
own." we seem to disagree on the long term goals.

> > - 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).  

How is policy and cost information fed back to the end-points ? 

> 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?

I am concerned because there is no possibility after this BoF to
determine the actual problem statement: is there a need for a linked
congestion control scheme because "MP-TCP" is introduced that is
perceived as a suitable evolution of TCP or do we want to solve a
broader objective for which MP-TCP could be an element of solution ?

Indeed, the first presentation of the BoF refers to offloading network
traffic engineering operations. Quoting that presentation "We now
understand that multipath TCP, if done appropriately, can go a long way
towards solving network-wide traffic engineering problems." That
statement raises the following issues:

o) traffic engineering (= put traffic where unused capacity is) enforces
"path diversity" by adapting traffic routing to network conditions with
joint traffic and resource-oriented performance objectives, i.e., if TE
is not used anymore what would be the incentive to keep diversity in
traffic routing (except local topological diversity often activated upon
failure occurrence); what would be the reduction factor of diversity ? 

o) self-fishdness: network will keep at least certain performance
objectives and individual end-point/sources each their own, I fail to
see how this proposal could reconcile both sides i.e. how does it ensure
that the network actions are not antagonistic to the transport one.

o) stability conditions (quoting one of the seminal paper in this space
"Stability of Multi-Path Dual Congestion Control Algorithms": "...it
would be desirable to find decentralized, scalable conditions for the
global stability of a multi-path congestion control algorithm in the
presence of propagation delays, ..." [...] "... we found decentralized,
scalable conditions for local stability in the presence of propagation
delays for a particular choice of scheme") are partially verified; this
leads me to think that part of this work would be better addressed in
the research space (but this is another discussion).

So in brief, by considering one aspect of the problem (linked congestion
control), one can not a priori state that the global objective (of
offloading network-wide traffic engineering) can be reached because the
underlying assumptions are not (yet) verified and are sometimes opposed
to the conditions at the inception of this scheme. On the other hand,
there is no apparent consensus to scope the work (from the replies I
received on this list) to a TCP congestion control scheme.

> > - 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. 

... and even if it received routing information, it can not enforce a
specific trajectory/ path to its packets (since the path followed by the
packet is under control of the network).

> 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.

As stated already, when dealing with failovers techniques reversion
mechanisms shall be considered otherwise facing overall deterioriation
over time.

-d.
> Scott
>