Re: Alternative Server Address Frames -01

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

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]>
Sent: Wednesday, July 22, 2026 0:47
To: QUIC WG <[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