24 Sep
2024
24 Sep
'24
2:12 a.m.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Happy Eyeballs
Abstract:
When a server's IPv4 path and protocol are working, but the server's
IPv6 path and protocol are not working, a dual-stack application that
initiates a connect experiences significant connection delay compared
to an IPv4-only application. This is undesirable because it causes the
dual-stack initiating entity to have a worse user experience. This XEP
defines how IETF's 'Happy Eyeballs' algorithm requirements that reduce
this user-visible delay are applied to XMPP.
URL: https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
8 Oct
8 Oct
10:17 p.m.
On 9/24/24 4:12 AM, Daniel Gultsch wrote:
I think a simpler version of this XEP would just be:
When you have domains/ports to connect to with the
same priority, use
the algorithm defined in https://datatracker.ietf.org/doc/html/rfc8305
to connect to them.
Re-explaining what is already defined in the SRV and XMPP RFCs is rather
confusing, I kept looking for something different and couldn't find it.
Additionally it implies this doesn't apply to all of the other
connection methods XMPP uses, XEP-0156 and XEP-0368 for starters, being
too specific is harmful here.
9 Oct
9 Oct
1:31 a.m.
On Wed, Oct 9, 2024 at 6:18 AM Travis Burtrum <travis(a)burtrum.org> wrote:
On 9/24/24 4:12 AM, Daniel Gultsch wrote:
I think a simpler version of this XEP would just be:
With my council hat on I’m going to vote +1 as I believe there is
enough text that people could start implementing it.
On a personal level and as a client developer I share a lot of the
concerns that Travis has.
I think a better version of the XEP would be "As soon as you have to
decide between IPv4 and IPv6 do happy eyeballs" which purposefully
leaves out all the steps that get you to this point as those can vary
widely.
Somewhat related as a client developer who (somewhat unfortunately)
has an incentive to just connect to something that works by every
means necessary I started to treat connections as successful only
after establishing a stream (instead of just a TCP connection). This
is to work around issues around misconfigured HAproxys that drop us
into the webserver instead of the XMPP server. Thus a simple happy
eyeballs that throws away the slower TCP connection instead of keeping
it as a fallback in case the faster one doesn’t work would probably
not work for me.
This is all to say; I can (or should) probably implement a XEP that
says "Use Happy Eyeballs" but the current proposed XEP has too many
words that I may or may not have to ignore to make it work in
practice. (I haven’t event gotten to the part where my client does
very aggressive "last working connection" caching for networks where
DNS simply doesn’t work)
cheers
Daniel
When you have domains/ports to connect to with
the same priority, use
the algorithm defined in
https://datatracker.ietf.org/doc/html/rfc8305
to connect to them.
Re-explaining what is already defined in the SRV and XMPP RFCs is rather
confusing, I kept looking for something different and couldn't find it.
Additionally it implies this doesn't apply to all of the other
connection methods XMPP uses, XEP-0156 and XEP-0368 for starters, being
too specific is harmful here. 
6:08 a.m.
Thanks Guus, for putting the effort into writing the XEP
But I am sorry, I feel similar like Travis. The main problem of the
ProtoXEP is that its scope is too narrow. Focusing solely on SRV records
and IPv4/IPv6 addresses misses the reality of diverse XMPP endpoint
discovery mechanisms used by clients today, such as XEP-0156 and XEP-0487.
That said, given the complexity that implementors face with the various
XMPP transport methods, like BOSH (XEP-0206), QUIC (XEP-0467), and
WebSockets (RFC 7395, XEP-0468), I see room for a XEP that guides
implementors on how to achieve a reliable connection, even in the
presence of challenging network conditions and hostile middleboxes.
Daniel already provides two excellent points for client implementers:
1. only assume that the connection was successful after the XMPP stream
was established
2. cache the last working connection's information (e.g., to work around
hostile networks where DNS does not work)
Furthermore, to deliver a good UX, clients need to try a limited amount
of connection endpoints in parallel [1]. At least, that is what Smack's
new connection architecture does. Some things that should be kept in
mind here. For example, this should still respect the priority groups of
SRV resource records.
A document outlining best practices for establishing XMPP connections
(both c2s and s2s), based on real-world experience, would be a valuable
resource for the XMPP ecosystem. This document should address the
challenges of diverse discovery mechanisms, transport methods, and
network conditions to ensure robust and reliable XMPP communication.
Finally, a nit: "Fully Qualified Domain Name" is not clearly specified,
I suggest using "DNS name" instead.
- Flow
1: Thanks to the current push towards featherweight threading systems in
programming languages, this can be implemented very efficiently
70
days inactive
85
days old
3 comments
3 participants
participants (3)
-
Daniel Gultsch -
Florian Schmaus -
Travis Burtrum