Re: More context on ATSSS use case

[Lucas Pardue <[e-mail]>]

Hey Hannu,

On Sun, 25 Oct 2020, 18:05 Flinck, Hannu (Nokia - FI/Espoo), <
[e-mail]> wrote:

> Hello David and others,
>
>
>
> ATSSS supports low latency applications in the following way (this is a
> quote from 23.700-93) as part of its “Priority-based” mode:
>
>
>
> “RTT Threshold: Supported by using the RTT estimation mechanism defined in
> draft-ietf-quic-recovery, with which the QUIC protocol can estimate the RTT
> of a QUIC connection. Example of ATSSS rule using this steering mode: "Send
> the traffic of App1 to the access with RTT < 100ms; if both accesses have
> RTT < 100ms, send it to non-3GPP access". … As long as the selected access
> has RTT < 100ms, the traffic can remain on this access.”
>
>
>
> I hope this clarifies that ATSSS is supporting what was called as
> Interactive service/Siri service in Christoph’s presentation.
>
>
>
> And as explained by Mirja earlier it is the application that requests what
> kind of session it would like to have.
>
So part of the benefit of QUIC is that connections can be reused for
different purposes. Using streams I can handle both an application that
requires low-latency (such as an API) along with bulk data transfer (such
as a software download) that has no hard requirement for completion time.

Iiuc ATSSS correctly, all it can do is forward QUIC packets. So how can it
pick the correct path the cases where a connection is mixed use?

Cheers
Lucas



>