Re: [IPv6] First hop selection [was: Adoption call for draft-bctb-6man-rfc6296-bis]

[Nick Buraglio <[e-mail]>]

On Wed, Mar 27, 2024 at 1:29 PM Brian E Carpenter
<[e-mail]> wrote:
>
> On 27-Mar-24 20:17, Vasilenko Eduard wrote:
> > Brian is replacing happy eyeballs
>
> Not exactly. Some apps will still want to make their own optimization. My thinking is that the more that information about the best {source, destination} pairs can be shared the better, so having the pairs ranked by the o/s itself will give the best possible results.

I agree with this.

>
>     Brian
>
>
> > because he is proposing to check DA properties in some tests. If we know enough about DA quality then we do not need happy eyeballs race/competition/duplicate_traffic.
> >
> > It is indeed better to cache and share such information per host, not per session.
> >
> > Ed/
> >
> > *From:* ipv6 <[e-mail]> *On Behalf Of * Ted Lemon
> > *Sent:* Tuesday, March 26, 2024 22:51
> > *To:* Brian E Carpenter <[e-mail]>
> > *Cc:* [e-mail]
> > *Subject:* Re: [IPv6] First hop selection [was: Adoption call for draft-bctb-6man-rfc6296-bis]
> >
> > Right. Such APIs exist, but socket/getaddrinfo isn’t that. I guess getaddrinfo could return a sorted list? But you still need to do happy eyeballs and track changes, so it’s not really adequate to do a synchronous API no matter what.
> >
> > Op di 26 mrt 2024 om 14:46 schreef Brian E Carpenter <[e-mail] <mailto:[e-mail]>>
> >
> >     On 27-Mar-24 06:15, Ted Lemon wrote:
> >      >
> >      >
> >      > Op di 26 mrt 2024 om 12:47 schreef Philip Homburg <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >
> >      >      >It seems like in order for this to work each possible destination address
> >      >      >has to be evaluated for reachability and then the set of source addresses
> >      >      >that could combine with it can be constrained using the selected interface
> >      >      >for that destination. And then you use source/dest address selection to
> >      >      >pick the source/destination pair from each of these result sets, and do
> >      >      >Happy Eyeballs to prioritize which S,D pairs you try. I don't see how you
> >      >      >could do this right if you start by picking a destination address.
> >      >
> >      >     When it comes to destination addresses we can make one of two assumptions:
> >      >     1) The Internet is professionally maintained and in general every destination
> >      >         address you find is reachable. In that case, order destination addresses
> >      >         in some way and try them in order. Of course sometimes there may be an
> >      >         issue, but if that is rare it is fine. And operators like users who
> >      >         complain because many operators are using user to detect problems. That
> >      >         why there is a push for IPv6-mostly.
> >      >     2) Whether a destination address works or not is mostly random. In that case
> >      >         get advanced forms of happy eyeballs to dynamically pick the most likely
> >      >         destination address and quickly try other ones as well to minimize
> >      >         impact on the user.
> >      >
> >      >     For each destination address you try, there is essentially the same reasoning
> >      >     for source addresses: in a well maintained network there is an algorithm
> >      >     to select source addresses. If there is more randomness then trying multiple
> >      >     source addresses for each destination address might be required.
> >      >
> >      >
> >      > Oh, right, rule 5.5 means we have multiple possible routes per destination to deal with. So we have an extra iteration to do there. But still, ideally if all upstreams are working, the first s,d pair that you choose this way will work.
> >
> >     To me, this very interesting discussion underlines that the model presented to the application by the BSD socket model via getaddrinfo() is at best unfriendly and at worst wrong. The app needs a sorted list of address pairs, not a sorted list of destination addresses with no information about the source addresses that will be used.
> >
> >         Brian
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> >     --------------------------------------------------------------------
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------