Re: Alternative Server Address Frames -01

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

> There is not, and the draft explicitly says so:
> > IPV4 and IPV6 entries before CURRENT_PATH have higher priority than the current path. The client SHOULD promptly validate these addresses and migrate to a validated address.

> This is independent of the current path's condition: the client SHOULD migrate as quickly as possible once it receives the frame.

Yes, I understand that. My point is different. And sorry, my question may have been unclear, let me rephrase:
> "Now, *after migration, at a later point in time*, what happens if the *new* current path becomes problematic (weak signal, faulty, latency increases,...)?"
Is the client allowed to migrate to a, so far, unused path from the first section?

In the example I gave earlier, the server sends a prio-1 path and a prio-10 path in the first section. The client immediately migrates to prio-1.
Then, later, prio-1 fails (or the client whishes to open a 2nd path with QUIC-MP). Does the client have to resort to a backup path?
Or, is the client allowed to use the prio-10 path instead of (or in addition to) the prio-1 path?

If the latter is allowed, then I'd argue that there is an implicit global ordering (if we adjust the priority values accordingly) that may be employed to simplify the usage with QUIC-MP.

If the latter is not allowed, could you maybe briefly explain or give an example why it is not okay to use first-section paths later on?
Is there maybe a supplementary document that I could have a look at?


A closely related (more theoretical) question is this:
The draft says a client SHOULD migrate as quickly as possible. What happens if a client does not do that? Is it allowed to migrate later (for any definition of "later")?
________________________________
From: Marten Seemann <[e-mail]>
Sent: Saturday, August 8, 2026 7:55
To: Zäschke Tilmann <[e-mail]>
Cc: Christian Huitema <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Alternative Server Address Frames -01

>  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?

There is not, and the draft explicitly says so:
> IPV4 and IPV6 entries before CURRENT_PATH have higher priority than the current path. The client SHOULD promptly validate these addresses and migrate to a validated address.

This is independent of the current path's condition: the client SHOULD migrate as quickly as possible once it receives the frame.



On Mon, 3 Aug 2026 at 14:34, Zäschke Tilmann <[e-mail]<mailto:[e-mail]>> wrote:
> QUIC multipath use the "PATH STATUS" to set which paths are "available"
> and which are marked as "backup". If the application sets several paths,
> it can set the status of these paths according to its preferences. The
> STATUS is not directly tied to the address.
>
> -- Christian Huitema

I'm not sure the ALTERNATIVE_ADDRESS frame is using a different
concept of "backup" as QUIC Multipath?

Example
-----------
a server sends am ALTERNATIVE_ADDRESS frame with 5 entries:
- prio 1:  192.168.0.1
- prio 10:  192.168.0.10
- CURRENT_PATH:  192.168.0.32
- prio 1:  192.168.0.101
- prio 10:  192.168.0.110

If the top preferred path works we get the following:
- 1 "active" paths: 192.168.0.1
- 1 ignored/dropped path: 192.168.0.10
- 1 "abandoned"/dropped path: 192.168.0.32
- 2 "backup" path:  192.168.0.101, 192.168.0.110

Question
------------
- Plain QUIC 9000: The new frame advertises "backup" addresses.
  Is the client asked to keep these locally for later use, or should they
  be dropped as soon as one of the preferred paths could be established?
- QUIC-MP: Should a client turn all preferred paths into "active" paths?
  I assume not?
- QUIC and QUIC-MP:
  Let's assume the top path fails after some time, the client would
  now resort to the first backup path, correct?
  Wouldn't it make sense to add the 2nd (unused) preferred path and
  the old CURRENT_PATH to the list of backup paths?
  After all, they were abandoned/dropped only because there seemed
  to be a better path available at the time, while the "backup" paths were
  clearly considered worse.


I wonder if the design could be changed to remove the sentinel and
introduce a single list of addresses globally ordered by priority.
- The list would contain the current path (or optionally multiple paths,
  in the case of QUIC-MP).
- The client would check all currently used addresses and try to connect
  through a preferred route.
- The client could keep all unused addresses as "backup".
- Optionally, addresses that were abandoned could also be added to the
  "backup" list, in case the preferred addresses all fail at a later point.

This should work seamlessly with QUIC-MP and would allow preferred
(but not "active") paths to be listed as backup.
Does that make sense?

Best,
Til
________________________________
From: Christian Huitema <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 31, 2026 16:56
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Alternative Server Address Frames -01


On 7/31/2026 4:54 AM, Zäschke Tilmann wrote:
> 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.


QUIC multipath use the "PATH STATUS" to set which paths are "available"
and which are marked as "backup". If the application sets several paths,
it can set the status of these paths according to its preferences. The
STATUS is not directly tied to the address.

-- Christian Huitema