Jeff, RTGWG,
The authors have requested the RTGWG to last call
draft-ietf-rtgwg-enterprise-pa-multihoming.
There was consensus that document is ready for the last call and the
authors have resolved all the comments received from the v6ops reivew.
The document discusses a range of solutions to enable legacy hosts to
select the right source address to use to reach a given destination.
However, I think that it complety ignores a very clean and efficient
solution to the multihoming problem : using multipath transport. The
IETF has already approved Multipath TCP in RFC6824. It is widely
deployed on one popular brand of smartphones and the MPTCP working is
progressing towards a standards-track version of MPTCP. In parallel, the
charter of the QUIC working group includes multipath support and there
is already an implementation which is available (see
https://www.multipath-quic.org). Multipath RTP has already been
discussed within the IETF as well.
With Multipath transport, the entreprise pa multihoming problem can be
solved in a much cleaner manner. A multipath transport has much more
flexibility in a multihomed site than a single path transport protocol.
With a multipath transport, it is possible to :
- select a source address at the beginning of a connection and switch to
another one during the lifetime of the connection without breaking it
- use multiple source addresses for a given connection to achieve best
performance (low delay, higher bandwidth by bonding, ...)
- learn a new source address when a link comes up and use it during a
connection
- react to congestion on one uplink by switching traffic to the other
uplinks
I think that it would make sense to either :
- discuss the impact of multipath transport in the current document (the
draft lists [I-D.ietf-mptcp-experience] in its references but does not
cite it in the text)
- indicate that the current document is restricted to single path
transport and write another document that describes how multipath
transport protocols can be used to solve the problems listed in this
document
I'm happy to contribute if the WG decides to go in either of these
directions.
Best regards,
Olivier Bonaventure
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
