Re: [v6ops] [IPv6] New Version Notification for draft-fbnvv-v6ops-site-multihoming-01.txt

[Mark Smith <[e-mail]>]

On Tue, 11 July 2023, 16:57 Vasilenko Eduard, <[e-mail]>
wrote:

> Hi Brian,
> It is a theoretical "good wish". Practically,
> MPTCP RFC blocks this possibility by the statement below, MPTCP in general
> has the goal to be transparent for the application.
> Hence, MPTCP is not capable in principle to solve any MHMP issues.
>

I don't understand this conclusion or assertion at all.

The ideal is that network and host multihoming is transparent to
applications.

We don't want to burden application developers with having to customise
their applications to suit multihomed networks or hosts.

The advantage of MPTCP or MPQUIC is the multipathing, providing potentially
both increased throughput and robustness is that those capabilities are
hidden in the transport layer.

(And the fundamental problem that makes network multihoming hard is that IP
addresses have been used as transport layer connection identifiers, such
that a transport layer connection can't continue if the underlying IP
address it is bound to stops working - the locator/identifier problem.

MPTCP and MPQUIC create their own connection identifiers, making the
connections far more independent of the IP addresses used to send the
packets between the endpoints.

TCP probably should have got it's own connection identifiers when it was
split off from IP in the 1970s.)



> I strongly suspect that QUIC real applications are not mangling with
> source IPv6 addresses - they use getaddrinfo() with the random next hop and
> source address selection.
>


You're guessing this.

Albeit, QUIC implementation of multipathing assumes that the application
> should be developed specially (MP QUIC by design is not transparent for the
> application layer).


And then coming to a conclusion based on your own guess you've just made.

Hence, QUIC is capable potentially to implement the logic for choosing the
> source address first (by bind()).
>
> Is anybody knows what the particular MP QUIC implementation is using for
> connection: getaddrinfo() or bind()?
> If any use bind() then it would resolve the most important MHMP issues
> (not all - see section 5.2.1)
>
> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2023 7:12 AM
> To: Vasilenko Eduard <[e-mail]>; Mark Smith <
> [e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [IPv6] New Version Notification for
> draft-fbnvv-v6ops-site-multihoming-01.txt
>
>
>
> Regards
>     Brian Carpenter
>
> On 10-Jul-23 19:27, Vasilenko Eduard wrote:
> > Hi Mark,
> > Thanks a lot for this message. I would discuss it with co-authors, but
> IMHO: we need to mention MPTCP and QUIC Multipath. Many may have the same
> illusion as you.
> >
> > I. Let's consider the situation when we have only one interface on the
> host. Multiple Carriers are connected upstream (on the CPE?).
> >
> > About what is chosen first - the next hop or the source address:
> > MPTCP (rfc6182) has strict in 2 places: " MPTCP MUST NOT be used for
> applications that request to bind to a specific address or interface, since
> such applications are making a deliberate choice of path in use ".
> > QUIC Multipath (draft-ietf-quic-multipath) has nothing about binding (or
> not binding) to a specific source address or interface.
> >
> > Hence, it looks like they both would probably use getaddrinfo() that
> would randomly choose the next hop and then randomly again source address
> (as explained in section 5.2 of draft-fbnvv-v6ops-site-multihoming) which
> does not help in multihoming, not at all.
>
> Multipath means: try all the available paths. If you have N source
> addresses and M destination addresses, that means N*M paths are available.
> The order of probing is of course a good question. I have no knowledge of
> QUIC but there's a little about MPTCP (and SHIM6) in this expired draft and
> some of its references:
> https://datatracker.ietf.org/doc/html/draft-naderi-ipv6-probing-01
>
>      Brian
>
>
>
> >
> > Do you know of any MPTCP or QUIC Multipath implementation that uses
> bind() initially (not getaddrinfo()) to reverse the logic (choose source
> address before the next hop)?
> > Then it would be a big deal that MUST be mentioned.
> >
> > Anyway, section 5.2 explains the situation properly for both cases
> (getaddrinfo() or bind()).
> > Just we need to mention that depending on what is chosen first for
> Multipathing solutions (next hop or source address) would drive the case to
> section 5.2.1 or 5.2.2.
> > Bind() (section 5.2.1) would have much more help to MHMP than
> getaddrinfo() (section 5.2.2).
> >
> > II. Let's consider the situation when we have many interfaces on the
> host. And at least one carrier is connected directly to the host (3GPP
> Modem?).
> >
> > Indeed, in this case, it does not matter what would be chosen first: the
> next hop or source address, getaddrinfo() would lead to the same result as
> Bind().
> > MHMP problem is resolved automatically. Does not matter whether MPTCP is
> used or not.
> > IMHO: we have lost the message in the draft that the host *directly
> connected* (by a separate interface) to at least one carrier has no MHMP
> problem in principle.
> >
> > Eduard
> > -----Original Message-----
> > From: Mark Smith [mailto:[e-mail]]
> > Sent: Monday, July 10, 2023 1:24 AM
> > To: Vasilenko Eduard <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [IPv6] New Version Notification for
> > draft-fbnvv-v6ops-site-multihoming-01.txt
> >
> > Hi,
> >
> > There's one multihoming solution that hasn't been mentioned in the draft
> that has been very widely deployed for both IPv4 and IPv6.
> >
> > Multipath TCP, deployed on Apple's IOS 7, and used by Siri.
> >
> > https://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mp
> > tcp.html
> >
> > https://blog.apnic.net/2022/08/23/analyzing-mptcp-adoption-in-the-inte
> > rnet/
> >
> > QUIC is gaining multipath capabilities as well.
> >
> > https://multipath-quic.org/
> >
> > The only issue left for a multi-homed network is to steer traffic out of
> the correct ISP connection based on source address so that the packets
> don't get dropped by BCP 38 filters. Source routing, segment routing or
> simply IP tunnelling from the first hop router directly to the correct ISP
> egress edge router via addition of an IP in IP or GRE header solves that.
> >
> > Regards,
> > Mark.
> >
> >
> >
> > On Fri, 7 Jul 2023 at 19:34, Vasilenko Eduard <vasilenko.eduard=
> [e-mail]> wrote:
> >>
> >> Hi IPv6 WG,
> >>
> >> We have heavily edited the draft between versions 00 and 01 (216
> commits on github).
> >>
> >> Primarily, we have expressed the general WG opinion in different
> sections on "how bad NAT and NPT are", propagating the hate to the table of
> content, including mentioning that NPT is experimental.
> >> Yet, we have not deleted solutions that exist in the real world - like
> we or not.
> >>
> >> The section on another "not good" solution is added - unfortunately,
> "application proxy" is very popular in Enterprise that may address the
> draft subject.
> >> Again, we were trying to be very negative on it, yet balanced - it is
> part of the real Enterprise practice and needs to be overviewed.
> >>
> >> More places to mention PVD when applicable.
> >>
> >> Paolo Nero has discovered that Microsoft is capable to use "preference"
> from RA even if RFC 4191 is not claimed.
> >>
> >> And many other small changes addressing comments from Tim Winters,
> >> Eric Vincke, Toerless Eckert, Lorenzo Colitti, Sheng Jiang, Erik
> Nygren, Fernando Gont, Jared Mauch, and Juliusz Chroboczek.
> >> Thanks for the feedback!
> >>
> >> Eduard
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> Sent: Friday, July 7, 2023 11:58 AM
> >> To: Vasilenko Eduard <[e-mail]>; Vasilenko Eduard
> >> <[e-mail]>; Klaus Frank <[e-mail]>;
> >> Nick Buraglio <[e-mail]>; Paolo Nero
> >> <[e-mail]>; Paolo Volpato <[e-mail]>
> >> Subject: New Version Notification for
> >> draft-fbnvv-v6ops-site-multihoming-01.txt
> >>
> >>
> >> A new version of I-D, draft-fbnvv-v6ops-site-multihoming-01.txt
> >> has been successfully submitted by Eduard Vasilenko and posted to the
> IETF repository.
> >>
> >> Name:           draft-fbnvv-v6ops-site-multihoming
> >> Revision:       01
> >> Title:          IPv6 Site connection to many Carriers
> >> Document date:  2023-07-07
> >> Group:          Individual Submission
> >> Pages:          38
> >> URL:
> https://www.ietf.org/archive/id/draft-fbnvv-v6ops-site-multihoming-01.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-fbnvv-v6ops-site-multihoming/
> >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming
> >> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-fbnvv-v6ops-site-multihoming-01
> >>
> >> Abstract:
> >>     Carrier resilience is a typical business requirement. IPv4
> >>     deployments have traditionally solved this challenge through private
> >>     internal site addressing in combination with separate NAT engines
> >>     attached to multiple redundant carriers. IPv6 brings support for
> >>     true end-to-end connectivity on the Internet, and hence NAT is the
> >>     least desirable option in such deployments. Native IPv6 solutions
> >>     for carrier resiliency, however, have drawbacks. This document
> >>     discusses all currently-available options to organize carrier
> >>     resiliency for a site, their strengths and weaknesses, and provides
> >>     a history of past IETF efforts approaching the issue. The views
> >>     presented here are the summary of discussions on the v6ops mailing
> >>     list and are not just the personal opinion of the authors.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>