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