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.
On 9/24/24 4:12 AM, Daniel Gultsch wrote:
URL: https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html
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.
On Wed, Oct 9, 2024 at 6:18 AM Travis Burtrum <travis@burtrum.org> wrote:
On 9/24/24 4:12 AM, Daniel Gultsch wrote:
URL: https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html
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.
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
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
participants (3)
-
Daniel Gultsch -
Florian Schmaus -
Travis Burtrum