Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify "multiple networks to choose between" #62

Open
nidhijaju opened this issue Nov 6, 2024 · 2 comments · May be fixed by #68
Open

Clarify "multiple networks to choose between" #62

nidhijaju opened this issue Nov 6, 2024 · 2 comments · May be fixed by #68
Labels

Comments

@nidhijaju
Copy link
Collaborator

From Jen Linkova on the mailing list:

The charter says "The algorithm takes as input a fully-qualified
domain name (FQDN), and results in a single established connection to
a single server IP address on a single network. While the algorithm
could apply to scenarios with multiple networks to choose between or
to use simultaneously, or could deal with pools of multiple
connections, such scenarios are out of scope for the working group
deliverables."

IMHO " multiple networks to choose between" needs clarifying. Does
multihoming, especially "multi-prefix, multi-router single-link"
topology or mPVD scenario are in scope?

@ekinnear
Copy link
Contributor

ekinnear commented Nov 6, 2024

@furry13 would "multiple network attachments" be any better? I think the intent is to cover all of the examples you gave, in the sense that what we'd be writing down is specific to multiple attempts originating a single source IP address.

ekinnear added a commit to ekinnear/draft-happy-eyeballs-v3 that referenced this issue Nov 6, 2024
@ekinnear ekinnear linked a pull request Nov 6, 2024 that will close this issue
@furry13
Copy link
Contributor

furry13 commented Nov 7, 2024

would "multiple network attachments" be any better?

Thank you Eric, I think it's definitely more clear and specify that multi-interface multihoming is out of scope, but a single interface multihoming is I guess that would mean that something might to be said in the draft about DNS resolution - like it's performed over the same interface? or do we ignore DNS split horizon? anyway, it's another issue). I'll send a PR for this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants