Re: Alternative Server Address Frames -01

[Zäschke Tilmann <[e-mail]>]

Hi Marten,

> These are fundamentally two very different kinds of addresses; it does not make sense to order them globally. Any address above the sentinel is one that the server is requesting the client to migrate to immediately, so the relative priorities of the backup addresses become irrelevant.

I don't quite understand what the difference is. The first step seems clear: If a client receives ALTERNATIVE_ADDRESS frame, it is supposed to switch to the highest ranked path in the first section.
Now, what happens if the current path becomes problematic (weak signal, faulty, latency increases,...)?
As I understand it, the client should switch to the highest ranked path. I.e. the highest ranked paths in the first set of addresses, or, if that set has no working path available, the highest ranked set in the second set (backup paths). So there seems to be a clear global ordering over all paths?

Is there a fundamental difference between the first set and the second set of paths, other than that the first set has higher priority than the current path while the second set has lower priority?
Basically, I don't understand why the two sets are separate?
I am asking because a global ordering may make it simpler for QUIC multipath.

> You’re right that the interactions with multipath are not fully fleshed out yet. In the most primitive form the server is simply asking the client to establish a new path; what happens with that path once it is established is left to the two endpoints. They could use the new path in addition to existing ones, or have it replace one or more of them.
> I’m not sure this needs to be specified in the present extension, since all of those options can already be expressed with the frames defined by QUIC multipath.

As I understand the ALTERNATIVE_ADDRESS frame may be sent at any time, multiple times, during a connection's lifetime.
What happens if a client already uses two paths when an ALTERNATIVE_ADDRESS frame arrives?
The sentinel can represent only one path.
It makes sense not to avoid having anything/too much in the draft that specifically handles QUIC Mutlipath.
There may be a simple solution to handle QUIC multipath without complicating the current proposal, but that would probably require a single ranked list of addresses instead of two independent sets...


Nit: Maybe the CURRENT_PATH would better be named CURRENT_ADDRESS, as it is part of the "Address" list in the parent frame?

Best,
Til
________________________________
From: Marten Seemann <[e-mail]>
Sent: Wednesday, July 29, 2026 17:11
To: Zäschke Tilmann <[e-mail]>
Cc: QUIC WG <[e-mail]>
Subject: Re: Alternative Server Address Frames -01

>  Section 5, page 4. "Priority Hint values have meaning only relative to other values on the same side of the CURRENT_PATH entry; values on opposite sides are unrelated."
Why is that? On a client, a naive implementation may just want to put all recommendations into a ranked list and then choose the best one. However, having a single ranked list is difficult if priority values are unrelated.  Maybe the design decision could be clarified, why are priorities are separate for each side of the sentinel?

These are fundamentally two very different kinds of addresses; it does not make sense to order them globally. Any address above the sentinel is one that the server is requesting the client to migrate to immediately, so the relative priorities of the backup addresses become irrelevant.

> Section 5, page 4. "Entries on each side MUST appear in ascending Priority Hint order."
If entries are ordered by priority. If the priority is implicitly given by the order, why do we need an additional field with a priority hint?

The priority field exists to allow equal priorities. For example, a server might have both a Wi-Fi and a cellular interface. All addresses associated with the Wi-Fi interface (IPv4 and IPv6) could share the same priority, while all addresses associated with the cellular interface would be given a different (most likely lower) priority.

> Section 7, page 5.
"This extension complements the Multipath extension for QUIC by allowing the server to contribute more information to the client for alternative paths."
I am not sure how this would work with QUIC multipath (QUIC-MP). In QUIC-MP you may have multiple paths. However, the CURRENT_PATH sentinel represents only a single path for which alternatives are given.
If I have two paths, A and B, how can a server communicate preferred alternatives for each path?
Or is the idea that alternatives are only valid for the path on which they are sent? Maybe that could be clarified?

You’re right that the interactions with multipath are not fully fleshed out yet. In the most primitive form the server is simply asking the client to establish a new path; what happens with that path once it is established is left to the two endpoints. They could use the new path in addition to existing ones, or have it replace one or more of them. I’m not sure this needs to be specified in the present extension, since all of those options can already be expressed with the frames defined by QUIC multipath.

On Wed, 29 Jul 2026 at 21:45, Zäschke Tilmann <[e-mail]<mailto:[e-mail]>> wrote:
Hi Marten,

This draft is very interesting, but I do have some questions:


  *
 Section 5, page 4.
"Priority Hint values have meaning only relative to other values on the same side of the CURRENT_PATH entry; values on opposite sides are unrelated."
Why is that? On a client, a naive implementation may just want to put all recommendations into a ranked list and then choose the best one. However, having a single ranked list is difficult if priority values are unrelated.  Maybe the design decision could be clarified, why are priorities are separate for each side of the sentinel?
  *
 Section 5, page 4.
"Entries on each side MUST appear in ascending Priority Hint order."
If entries are ordered by priority. If the priority is implicitly given by the order, why do we need an additional field with a priority hint?
  *
Section 7, page 5.
"This extension complements the Multipath extension for QUIC by allowing the server to contribute more information to the client for alternative paths."
I am not sure how this would work with QUIC multipath (QUIC-MP). In QUIC-MP you may have multiple paths. However, the CURRENT_PATH sentinel represents only a single path for which alternatives are given.
If I have two paths, A and B, how can a server communicate preferred alternatives for each path?
Or is the idea that alternatives are only valid for the path on which they are sent? Maybe that could be clarified?


Please let me know if you prefer the discussion on GitHub or somewhere else.

Thanks and kind regards,
Tilmann Zäschke

________________________________
From: Marten Seemann <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 22, 2026 0:47
To: QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: Alternative Server Address Frames -01


Hi all,

After a couple of very helpful conversations at the IETF meeting in Vienna, we published -01 of the Alternative Server Address Frames draft:

https://datatracker.ietf.org/doc/draft-munizaga-quic-alternative-server-address/01/

The frame format has changed. An ALTERNATIVE_ADDRESS frame now advertises the complete set of available server addresses, indicating whether an address is preferred over the current path or is intended as a backup.

The purpose remains to let a server advertise alternative addresses to which the client can migrate. NAT traversal and hole punching remain out of scope, though I expect my NAT traversal draft to use this draft as a building block.

Cheers,
Marten