Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]

[Spencer Dawkins at IETF <[e-mail]>]

Dear QUICsters,

I have a couple of hats, but NONE of them apply in this e-mail. So, just
speaking for me.

On Wed, Apr 1, 2020 at 11:50 AM Matt Joras <[e-mail]> wrote:

> On Wed, Apr 1, 2020 at 9:16 AM Magnus Westerlund <magnus.westerlund=
> [e-mail] <[e-mail]..org>> wrote:
>
>> QUIC WG,
>>
>> The IETF has received the attached Liasion statement (
>> https://datatracker.ietf.org/liaison/1678/) that is intended for the
>> QUIC WG.
>> Please review it and the WG should considerd sending information to 3GPP
>> as
>> requested at key points in the process of the multi-path
>> extension/version of
>> QUIC.
>>
>> Cheers
>>
>> Magnus Westerlund
>> TSV AD
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Liaison Statement Management Tool <[e-mail]>
>> To: The IETF Chair <[e-mail]>
>> Cc: The IETF Chair <[e-mail]>, The IESG <[e-mail]>,
>> [e-mail], Gonzalo Camarillo <[e-mail]>
>> Bcc:
>> Date: Wed, 01 Apr 2020 08:09:28 -0700
>> Subject: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"
>> Title: LS on need for Multi-Path QUIC for ATSSS
>> Submission Date: 2020-04-01
>> URL of the IETF Web page: https://datatracker.ietf.org/liaison/1678/
>>
>> From: Susanna Kooistra <[e-mail]>
>> To: The IETF Chair <[e-mail]>
>> Cc: The IESG <[e-mail]>,The IETF Chair <[e-mail]>,Gonzalo
>> Camarillo <[e-mail]>
>> Response Contacts: [e-mail]
>> Technical Contacts:
>> Purpose: For information
>>
>> Body: 1. Overall Description:
>> 3GPP has approved the study item on “Study on Access Traffic Steering,
>> Switch and Splitting support in the 5G system architecture Phase 2” as part
>> of Release 17.
>>
>> This study aims to investigate the extension of Rel-16 ATSSS feature
>> enabling the support of steering, switching and splitting the traffic of a
>> PDU session supported over multiple accesses (namely 3GPP and Non-3GPP
>> access), including the following objective:
>>
>> -       Whether and how to support additional steering methods(s).
>> Proposed solutions shall be based on IETF protocols or extension of such
>> protocols (i.e. QUIC/MP-QUIC).
>>
>> Please see attached document for details on study item objectives and
>> timelines.
>>
>> A small complaint. The attached documents are in a proprietary format
> (Microsoft Word) that doesn't really render properly in freely available
> software.
>

That's fair. PDF versions are attached. If I can provide some other format,
please let me know.


> Secondly, the information therein is pretty "raw", appearing to be some
> sort minutes with annotations. I don't know how we are supposed to get any
> usable information from these document without being actively involved in
> 3GPP.
>

Not quite "minutes", but "output of the most recent SA plenary meeting,
reflecting all agreed contributions" (don't ask). These are usually
distributed in "rm" (revision marks) and "cl" (clean) formats. You can
safely ignore the "rm" version unless you are curious about what changed
recently.

Yes, you're right, the most effective way for any SDO to work with the IETF
is by sending humans to the IETF to participate as individuals. I'm now
participating in 3GPP ATSSS work as well as in the IETF, and I don't think
I'm the only one, so at least some crossover exists.


> The work on the study has not yet started in 3GPP, and there are thus no
>> agreed conclusions. . The goal is to enable steering, switching and
>> splitting of traffic (primarily UDP) across multiple accesses, including
>> latency sensitive and real time traffic. Therefore 3GPP is interested to
>> receive regular feedback on progress and prioritization on the multipath
>> extensions to QUIC.
>>
>
IMO, this is actually a victory - for most of the time that 3GPP has been
trying to work with the IETF, it's been from the CT ("stage 3") protocol
groups), where there was a very short timeline between contact with the
IETF and the deadline for inclusion of IETF technology in a specification.
This is coming from SA, which does requirements and architecture, and even
then, they're just getting started. So that kind of running start ought to
be helpful.

(As an AD, I was begging liaisons from 3GPP to send us what they are
thinking about earlier in the process. This looks like that finally
happened, so I'd hate for the IETF to drop it on the ground, but I'm not an
AD, so that doesn't matter now)


>
>> When multipath was discussed in Zurich, the opinion of the room seemed to
> be that we should not be endeavoring on this work without an eminently
> clear use case and required feeatures. This statement from 3GPP does not
> yet describe a clear use case. Without an explicit problem statement and an
> enumeration of the features that are going to be required of a multipath
> QUIC extension, I don't think the WG should begin work designing such an
> extension, having other useful work that can be done.
>

I understand most of what's in
https://datatracker.ietf.org/meeting/interim-2020-quic-01/materials/minutes-interim-2020-quic-01-202002050930.html#multipath-extensions-for-quic,
although I wasn't at the interim, and I've had conversations about
multipath with Lars (which included some concerns that weren't included in
the Zurich discussions).

Is it worth me trying to write something up, explaining where the QUIC
working group was on this, the last time it was discussed? That could go
back to 3GPP as a formal liaison response, or I could just tell the ATSSS
people on a 3GPP conference call - whatever works.

Best,

Spencer


> 2. Actions:
>> To IETF group:
>> ACTION:         3GPP SA kindly requests IETF to take the above
>> information into account when discussing future work in prioritizing the
>> multipath work for QUIC.
>>
>>
>> 3. Date of Next TSG-SA Meetings:
>> 3GPP TSG SA#88  17th – 19th June 2020   Malmö, SWEDEN
>> 3GPP TSG SA#89  16th – 18th September 2020      Funchal (Madeira),
>> Portugal
>> Attachments:
>>
>>     SP-200095_S2-2002593_SP-190558_Revised_SID_FS_ATSSS_Ph2_rm
>>
>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-04-01-3gpp-ietf-ls-on-need-for-multi-path-quic-for-atsss-attachment-1.doc
>>
>>     SP-200095_S2-2002593_SP-190558_Revised_SID_FS_ATSSS_Ph2_cl
>>
>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-04-01-3gpp-ietf-ls-on-need-for-multi-path-quic-for-atsss-attachment-2.doc
>>
>>     SP-200289_SP-200264_cleaned
>>
>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-04-01-3gpp-ietf-ls-on-need-for-multi-path-quic-for-atsss-attachment-3.docx
>>
>>
>>
> Matt Joras
>