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

Charter updates based on side meeting #53

Merged
merged 4 commits into from
Aug 20, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 33 additions & 17 deletions charter.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,13 @@
## HAPPY WG (Heuristics and Algorithms to Prioritize Protocol deploYment)
## HAPPIE WG (Heuristics and Algorithms to Prioritize Protocol Initiation and Establishment)

RFC 8305 defined “Happy Eyeballs Version 2”, which described a client algorithm
for asynchronous resolution of and connection attempts to different server IP
address options, aiming to improve IPv6 usage without adding risk due to
misconfigured networks or servers. The algorithm focused specifically on
optimizing TCP connection establishment. The name “happy eyeballs” itself refers
to how a user’s eyeballs are happier when content loads more quickly because
they don’t need to wait for timeouts due to misconfigured deployments.
address options, aiming to improve IPv6 usage without degrading connection
establishment success rates due to misconfigured networks or servers. The
algorithm focused specifically on optimizing TCP connection establishment.
The name “happy eyeballs” itself refers to how a user’s eyeballs are happier
when content loads more quickly because they don’t need to wait for timeouts
due to misconfigured deployments.

Since the publication of RFC 8305, several changes to common protocols and
server deployments have occurred that require a revision of the algorithm. Some
Expand All @@ -17,17 +18,29 @@ of these include:
- Introduction of Service Binding DNS resource records (SVCB and HTTPS RRs) that
provide richer information about available services and record priorities
and change the selection and sorting of addresses for Happy Eyeballs.
- Preparations for the standardization of TLS Encrypted Client Hello.
- Preparations for the standardization of TLS Encrypted Client Hello, which
can impact which servers a client is willing to connect to based on available
security properties.
- Increased deployment and refinement of IPv6-only and IPv6-mostly networks.

The HAPPY working group will deliver an updated version of the Happy Eyeballs
The HAPPIE working group will deliver an updated version of the Happy Eyeballs
algorithm that incorporates changes to account for these protocol developments.
The algorithm should focus on deployed network scenarios and should be guided by
data on user experience focused performance in those scenarios. The working
group can also document the impact of the Happy Eyeballs algorithm on the
detection of misconfigured deployments and can document recommendations on how
to report such cases that might otherwise be hidden due to automatic switching
from one technology to another.
The algorithm will focus on realistic network scenarios and should be guided by
performance data measured in deployed networks. Although the algorithm
needs to be generally applicable, platform-specific or deployment-specific
considerations should be documented to help guide implementers. The algorithm
should have tunable input values that can reflect
the preferences of a client implementation; defaults for these input values
can be based on working group consensus for standard behavior
(such as preferring IPv6 connections, preferring faster establishment times,
etc.), but allow for variation.

The working group will also document the impact of the Happy Eyeballs algorithm
on the detection of misconfigured deployments and may provide recommendations on
how to report such cases that might otherwise be hidden due to automatic switching
from one technology to another. Any recommended reporting mechanisms need to
preserve user privacy, allow for accurate detection of broken deployments,
and produce reports that are actionable.

The working group will focus on a connection establishment algorithm that
runs on clients. The algorithm takes as input a fully-qualified domain name
Expand All @@ -39,12 +52,15 @@ working group deliverables.

The rationale for having a working group for this work, instead of hosting it in
V6OPS, is the increased cross-functional nature of the algorithm. As such, the
HAPPY working group will review its work with groups such as V6OPS, TSVWG, QUIC,
HAPPIE working group will review its work with groups such as V6OPS, TSVWG, QUIC,
HTTPBIS, DNSOP, and TLS.

The working group’s core deliverables are:

- Develop a standards-track document for Happy Eyeballs Version 3
- Measure the effectiveness of the algorithm during development. This effort
- Developing a standards-track document for Happy Eyeballs Version 3
- Measuring the effectiveness of the algorithm during development. This effort
does not necessarily need to lead to a published document, but should be
captured in presentations, working group wikis, etc.
- Producing a document that explains the impact of Happy Eyeballs on
detecting and measuring broken deployments, with recommendations on
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I missed something, but I thought we agreed to have a wiki page or something to document this information (i.e. the previous deliverable)?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I view the previous bullet as "the measurements that back up the algorithm", and this one as "reporting brokenness"

how to report errors in a private, accurate, and actionable way.
Loading