Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

From: Christian Huitema <[email-masked]>
Date: Tue, 1 Dec 2020 00:19:23 -0800

The policy on liaisons is indeed for the IAB to decide, not individual 
working groups let alone individual members of working groups. I read 
Marten's request as a polite suggestion, not an attempt to set policy. 
On the other hand, I think it would be a really good idea for the IAB to 
take that suggestion and make it part of our liaison policy, stating 
that the IETF would prefer to receive liaison statements in either text 
or PDF format...

-- Christian Huitema

On 11/30/2020 11:37 PM, Gonzalo Camarillo wrote:
>
> Hi Marten,
>
> our friends from 3GPP can probably convert that into a PDF trivially. 
> In any case, for future liaisons, is this a new official policy 
> approved by the IESG to handle incoming liaisons? If so, it would be 
> useful to inform all our liaison managers to make our expectations on 
> other organizations clear and avoid this type of back-and-forth 
> exchanges.
>
> Cheers,
>
> Gonzalo
>
> *From:* Marten Seemann <[email-masked]>
> *Sent:* Tuesday, December 1, 2020 06:17
> *To:* Liaison Statement Management Tool <[email-masked]>
> *Cc:* Lucas Pardue <[email-masked]>; Lars Eggert 
> <[email-masked]>; Magnus Westerlund <[email-masked]>; 
> [email-masked]; Gonzalo Camarillo 
> <[email-masked]>; [email-masked]; 
> [email-masked]; QUIC Discussion List <[email-masked]>; Martin Duke 
> <[email-masked]>
> *Subject:* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
>
> Would it be possible to publish this document in a format that can be 
> opened by everyone without using proprietary software?
>
> Thank you,
>
> Marten
>
> On Mon, Nov 30, 2020 at 10:40 PM Liaison Statement Management Tool 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Title: LS on ATSSS Phase 2 conclusions
>     Submission Date: 2020-11-30
>     URL of the IETF Web page:
>     https://datatracker.ietf.org/liaison/1710/
>     <https://datatracker.ietf.org/liaison/1710/>
>
>     From: Susanna Kooistra <[email-masked]
>     <mailto:[email-masked]>>
>     To: Lars Eggert <[email-masked] <mailto:[email-masked]>>,Lucas
>     Pardue <[email-masked]
>     <mailto:[email-masked]>>
>     Cc: QUIC Discussion List <[email-masked]
>     <mailto:[email-masked]>>,Martin Duke <[email-masked]
>     <mailto:[email-masked]>>,Magnus Westerlund
>     <[email-masked]
>     <mailto:[email-masked]>>,Lucas Pardue
>     <[email-masked]
>     <mailto:[email-masked]>>,Lars Eggert <[email-masked]
>     <mailto:[email-masked]>>,[email-masked]
>     <mailto:[email-masked]>,[email-masked]
>     <mailto:[email-masked]>
>     Response Contacts: [email-masked]
>     <mailto:[email-masked]>,[email-masked]
>     <mailto:[email-masked]>
>     Technical Contacts:
>     Purpose: For information
>
>     Body:
>     Attachments:
>
>         S2-2009400_8852r02
>     https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-11-30-3gpp-tsgsa-sa2-quic-ls-on-atsss-phase-2-conclusions-attachment-1.doc
>     <https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-11-30-3gpp-tsgsa-sa2-quic-ls-on-atsss-phase-2-conclusions-attachment-1.doc>
>

---

From: <[email-masked]>
Date: Tue, 1 Dec 2020 09:43:02 +0000

Hi,

Here is a pdf version.

Regards,

Lionel

De : Marten Seemann [mailto:[email-masked]]
Envoyé : mardi 1 décembre 2020 05:17
À : Liaison Statement Management Tool <[email-masked]>
Cc : Lucas Pardue <[email-masked]>; Lars Eggert <[email-masked]>; Magnus Westerlund <[email-masked]>; MORAND Lionel TGI/OLN <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; QUIC Discussion List <[email-masked]>; Martin Duke <[email-masked]>
Objet : Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Would it be possible to publish this document in a format that can be opened by everyone without using proprietary software?

Thank you,
Marten

On Mon, Nov 30, 2020 at 10:40 PM Liaison Statement Management Tool <[email-masked]<mailto:[email-masked]>> wrote:
Title: LS on ATSSS Phase 2 conclusions
Submission Date: 2020-11-30
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1710/

From: Susanna Kooistra <[email-masked]<mailto:[email-masked]>>
To: Lars Eggert <[email-masked]<mailto:[email-masked]>>,Lucas Pardue <[email-masked]<mailto:[email-masked]>>
Cc: QUIC Discussion List <[email-masked]<mailto:[email-masked]>>,Martin Duke <[email-masked]<mailto:[email-masked]>>,Magnus Westerlund <[email-masked]<mailto:[email-masked]>>,Lucas Pardue <[email-masked]<mailto:[email-masked]>>,Lars Eggert <[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]>,[email-masked]<mailto:[email-masked]>
Response Contacts: [email-masked]<mailto:[email-masked]>,[email-masked]<mailto:[email-masked]>
Technical Contacts:
Purpose: For information

Body:
Attachments:

    S2-2009400_8852r02

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 1 Dec 2020 19:29:24 +0900

Lionel, thank you for converting the statement to PDF.

Reading the document, I have one question.

"The simultaneous transmission of a data flow across two accesses should
not result in out-of-order delivery"

I wonder what this sentence means. Is it suggesting that UPF (and possibly
UE) would buffer packets that arrive on the faster path until the packets
that were sent on the slower path reach that node? To give an example,
let's say that UE has sent three packets: packet 1 sent using WiFi, packet
2 using LTE, packet 3 using WiFi. UPF receives packets in the order of 1,
3, 2. Is UPF expected to postpone the forwarding of packet 3 until it
receives packet 2?

I raise the question, because during the interim, some have pointed out
that such buffering has negative effects on loss recovery, and that we
should devote our efforts to designing an end-to-end multi-path design,
rather than having an intermediary that aggregates paths (in this case UPF).

2020年12月1日(火) 18:43 <[email-masked]>:

> Hi,
>
>
>
> Here is a pdf version.
>
>
>
> Regards,
>
>
>
> Lionel
>
>
>
> *De :* Marten Seemann [mailto:[email-masked]]
> *Envoyé :* mardi 1 décembre 2020 05:17
> *À :* Liaison Statement Management Tool <[email-masked]>
> *Cc :* Lucas Pardue <[email-masked]>; Lars Eggert <
> [email-masked]>; Magnus Westerlund <[email-masked]>;
> MORAND Lionel TGI/OLN <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> QUIC Discussion List <[email-masked]>; Martin Duke <[email-masked]
> >
> *Objet :* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
>
>
>
> On Mon, Nov 30, 2020 at 10:40 PM Liaison Statement Management Tool <
> [email-masked]> wrote:
>
> From: Susanna Kooistra <[email-masked]>
> To: Lars Eggert <[email-masked]>,Lucas Pardue <[email-masked]
> >
> Cc: QUIC Discussion List <[email-masked]>,Martin Duke <
> [email-masked]>,Magnus Westerlund <[email-masked]>,Lucas
> Pardue <[email-masked]>,Lars Eggert <[email-masked]>,
> [email-masked],[email-masked]
> Response Contacts: [email-masked],[email-masked]
> Technical Contacts:
> Purpose: For information
>
> Body:
> Attachments:
>
>     S2-2009400_8852r02
>

-- 
Kazuho Oku

---

From: <[email-masked]>
Date: Tue, 1 Dec 2020 11:07:00 +0000

Thanks for raising this topic. With https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-01 we consider exactly that and try to provide input to develop/discuss different re-ordering strategies. My personal belief is, that without any re-ordering implementation in the UPF or UE the end-to-end delivery will be worse.

From: QUIC <[email-masked]> On Behalf Of Kazuho Oku
Sent: Dienstag, 1. Dezember 2020 11:29
To: [email-masked]
Cc: Magnus Westerlund <[email-masked]>; Liaison Statement Management Tool <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Lucas Pardue <[email-masked]>; Marten Seemann <[email-masked]>; Lars Eggert <[email-masked]>; QUIC Discussion List <[email-masked]>; Martin Duke <[email-masked]>
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

"The simultaneous transmission of a data flow across two accesses should not result in out-of-order delivery"

I wonder what this sentence means. Is it suggesting that UPF (and possibly UE) would buffer packets that arrive on the faster path until the packets that were sent on the slower path reach that node? To give an example, let's say that UE has sent three packets: packet 1 sent using WiFi, packet 2 using LTE, packet 3 using WiFi. UPF receives packets in the order of 1, 3, 2. Is UPF expected to postpone the forwarding of packet 3 until it receives packet 2?

I raise the question, because during the interim, some have pointed out that such buffering has negative effects on loss recovery, and that we should devote our efforts to designing an end-to-end multi-path design, rather than having an intermediary that aggregates paths (in this case UPF).

2020年12月1日(火) 18:43 <[email-masked]<mailto:[email-masked]>>:
Hi,

Here is a pdf version.

Regards,

Lionel

De : Marten Seemann [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 1 décembre 2020 05:17
À : Liaison Statement Management Tool <[email-masked]<mailto:[email-masked]>>
Cc : Lucas Pardue <[email-masked]<mailto:[email-masked]>>; Lars Eggert <[email-masked]<mailto:[email-masked]>>; Magnus Westerlund <[email-masked]<mailto:[email-masked]>>; MORAND Lionel TGI/OLN <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; QUIC Discussion List <[email-masked]<mailto:[email-masked]>>; Martin Duke <[email-masked]<mailto:[email-masked]>>
Objet : Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 1 Dec 2020 15:13:58 +0000

True, Christian; it should be the IAB, not the IESG. Thanks.

Gonzalo

From: Christian Huitema <[email-masked]>
Sent: Tuesday, December 1, 2020 10:19
To: Gonzalo Camarillo <[email-masked]>; Marten Seemann <[email-masked]>; Liaison Statement Management Tool <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Lucas Pardue <[email-masked]>; Lars Eggert <[email-masked]>; QUIC Discussion List <[email-masked]>; Martin Duke <[email-masked]>; IAB Chair <[email-masked]>
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

The policy on liaisons is indeed for the IAB to decide, not individual working groups let alone individual members of working groups. I read Marten's request as a polite suggestion, not an attempt to set policy. On the other hand, I think it would be a really good idea for the IAB to take that suggestion and make it part of our liaison policy, stating that the IETF would prefer to receive liaison statements in either text or PDF format...

-- Christian Huitema

our friends from 3GPP can probably convert that into a PDF trivially. In any case, for future liaisons, is this a new official policy approved by the IESG to handle incoming liaisons? If so, it would be useful to inform all our liaison managers to make our expectations on other organizations clear and avoid this type of back-and-forth exchanges.

Cheers,

Gonzalo

From: Marten Seemann <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, December 1, 2020 06:17
To: Liaison Statement Management Tool <[email-masked]><mailto:[email-masked]>
Cc: Lucas Pardue <[email-masked]><mailto:[email-masked]>; Lars Eggert <[email-masked]><mailto:[email-masked]>; Magnus Westerlund <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gonzalo Camarillo <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; QUIC Discussion List <[email-masked]><mailto:[email-masked]>; Martin Duke <[email-masked]><mailto:[email-masked]>
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

---

From: Kevin <[email-masked]>
Date: Tue, 1 Dec 2020 12:19:33 -0500

Perhaps an RTF format such as:
https://www.dropbox.com/sh/yve5r2l1v8we6ly/AACjdz3_ccNSskHHsQbHwlTka?dl=1

Kevin

http://kclive.buzzsprout.com

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: <[email-masked]>
Date: Tue, 1 Dec 2020 19:14:22 +0000

Including Apostolis into the loop.

De : [email-masked] [mailto:[email-masked]]
Envoyé : mardi 1 décembre 2020 12:07
À : [email-masked]; MORAND Lionel TGI/OLN <[email-masked]>
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Kazuho Oku
Sent: Dienstag, 1. Dezember 2020 11:29
To: [email-masked]<mailto:[email-masked]>
Cc: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>; Liaison Statement Management Tool <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Lucas Pardue <[email-masked]<mailto:[email-masked]>>; Marten Seemann <[email-masked]<mailto:[email-masked]>>; Lars Eggert <[email-masked]<mailto:[email-masked]>>; QUIC Discussion List <[email-masked]<mailto:[email-masked]>>; Martin Duke <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 2 Dec 2020 20:54:37 -0800

Speaking only as a user of computer technology, thanks for making this more
palatable as a PDF. A few questions:

- I am a bit confused by the picture, and Spencer or someone else can point
me to something that I haven't read yet -- I thought the QUIC connection
was between the remote server and the UE, not between the UPF and the UE.
Am I missing something?

- Assuming that the QUIC connection is between the UE and the remote
server: Since only endpoints can see the packet numbers, how are the
packets supposed to be re-sequenced at any point in the middle (the UPF)?

Thanks!
- jana

On Tue, Dec 1, 2020 at 11:14 AM <[email-masked]> wrote:

> *De :* [email-masked] [mailto:[email-masked]]
> *Envoyé :* mardi 1 décembre 2020 12:07
> *À :* [email-masked]; MORAND Lionel TGI/OLN <[email-masked]
> >
> *Cc :* [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Objet :* RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
>
>
>
> Thanks for raising this topic. With
> https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-01 we
> consider exactly that and try to provide input to develop/discuss different
> re-ordering strategies. My personal belief is, that without any re-ordering
> implementation in the UPF or UE the end-to-end delivery will be worse.
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of *Kazuho Oku
> *Sent:* Dienstag, 1. Dezember 2020 11:29
> *To:* [email-masked]
> *Cc:* Magnus Westerlund <[email-masked]>; Liaison
> Statement Management Tool <[email-masked]>;
> Lucas Pardue <[email-masked]>; Marten Seemann <
> [email-masked]>; Lars Eggert <[email-masked]>; QUIC Discussion
> List <[email-masked]>; Martin Duke <[email-masked]>

---

From: Waqar Zia <[email-masked]>
Date: Thu, 3 Dec 2020 08:48:55 +0000

Hi Jana,

The diagram is the correct depiction as I see: the MP-QUIC connection is indeed expected to be between the UE and the UPF, not between the UE and a (3GPP-) external server. Hence the reordering that may happen due to use of two different access technologies between the UE and UPF needs to be fixed at the UPF for the uplink and at the UE for the downlink.

Best regards,
Waqar.

From: QUIC <[email-masked]> On Behalf Of Jana Iyengar
Sent: 03 December 2020 05:55
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Apostolis Salkintzis <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

CAUTION: This email originated from outside of the organization.
Speaking only as a user of computer technology, thanks for making this more palatable as a PDF. A few questions:

- I am a bit confused by the picture, and Spencer or someone else can point me to something that I haven't read yet -- I thought the QUIC connection was between the remote server and the UE, not between the UPF and the UE. Am I missing something?
- Assuming that the QUIC connection is between the UE and the remote server: Since only endpoints can see the packet numbers, how are the packets supposed to be re-sequenced at any point in the middle (the UPF)?

Thanks!
- jana

On Tue, Dec 1, 2020 at 11:14 AM <[email-masked]<mailto:[email-masked]>> wrote:
Including Apostolis into the loop.

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 1 décembre 2020 12:07
À : [email-masked]<mailto:[email-masked]>; MORAND Lionel TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

Thank you.

---

From: <[email-masked]>
Date: Thu, 3 Dec 2020 09:32:40 +0000

Full ACK. 3GPP requests MP-QUIC to be applied between UE and UPF. Encapsulating the traffic from services on the UE into this MP-QUIC connection allows communication with the respective remote servers.

Br

Markus

From: Waqar Zia <[email-masked]>
Sent: Donnerstag, 3. Dezember 2020 09:49
To: Jana Iyengar <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Apostolis Salkintzis <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Amend, Markus <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi Jana,

Best regards,
Waqar.

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Jana Iyengar
Sent: 03 December 2020 05:55
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Apostolis Salkintzis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Thanks!
- jana

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

Thank you.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 3 Dec 2020 02:01:22 -0800

Are the special ordering concerns beyond single streams?

I don’t think it is useful to reorder datagram frames and streams are by
definition ordered within a stream and not across streams in QUIC v1 and I
don’t see any multipath design that would change that.

If datagram frames were to be ordered, you would loose the ASAP property
you want from those frames, and if cross stream ordering is applied, you
introduce HoL.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 3 December 2020 at 10.33.17, [email-masked] (
[email-masked]) wrote:

Full ACK. 3GPP requests MP-QUIC to be applied between UE and UPF.
Encapsulating the traffic from services on the UE into this MP-QUIC
connection allows communication with the respective remote servers.

Br

Markus

*From:* Waqar Zia <[email-masked]>
*Sent:* Donnerstag, 3. Dezember 2020 09:49
*To:* Jana Iyengar <[email-masked]>; [email-masked]
*Cc:* [email-masked]; [email-masked]; [email-masked];
Apostolis Salkintzis <[email-masked]>; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Amend, Markus <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
*Subject:* RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi Jana,

The diagram is the correct depiction as I see: the MP-QUIC connection is
indeed expected to be between the UE and the UPF, not between the UE and a
(3GPP-) external server. Hence the reordering that may happen due to use of
two different access technologies between the UE and UPF needs to be fixed
at the UPF for the uplink and at the UE for the downlink.

Best regards,

Waqar.

*From:* QUIC <[email-masked]> *On Behalf Of *Jana Iyengar
*Sent:* 03 December 2020 05:55
*To:* [email-masked]
*Cc:* [email-masked]; [email-masked]; [email-masked];
Apostolis Salkintzis <[email-masked]>; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
*Subject:* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

*CAUTION*: This email originated from outside of the organization.

Thanks!

- jana

*À :* [email-masked]; MORAND Lionel TGI/OLN <[email-masked]>

*From:* QUIC <[email-masked]> *On Behalf Of *Kazuho Oku
*Sent:* Dienstag, 1. Dezember 2020 11:29
*To:* [email-masked]
*Cc:* Magnus Westerlund <[email-masked]>; Liaison Statement
Management Tool <[email-masked]>; [email-masked];
[email-masked]; [email-masked]; Lucas Pardue <
[email-masked]>; Marten Seemann <[email-masked]>; Lars
Eggert <[email-masked]>; QUIC Discussion List <[email-masked]>; Martin Duke
<[email-masked]>
*Subject:* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi,

Here is a pdf version.

Regards,

Lionel

*De :* Marten Seemann [mailto:[email-masked]]
*Envoyé :* mardi 1 décembre 2020 05:17
*À :* Liaison Statement Management Tool <[email-masked]>
*Cc :* Lucas Pardue <[email-masked]>; Lars Eggert <
[email-masked]>; Magnus Westerlund <[email-masked]>;
MORAND Lionel TGI/OLN <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]; QUIC
Discussion List <[email-masked]>; Martin Duke <[email-masked]>
*Objet :* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Thank you,

Marten

From: Susanna Kooistra <[email-masked]>
To: Lars Eggert <[email-masked]>,Lucas Pardue <[email-masked]>
Cc: QUIC Discussion List <[email-masked]>,Martin Duke <
[email-masked]>,Magnus Westerlund
<[email-masked]>,Lucas
Pardue <[email-masked]>,Lars Eggert <[email-masked]>,
[email-masked],[email-masked]
Response Contacts: [email-masked],[email-masked]
Technical Contacts:
Purpose: For information

Body:
Attachments:

    S2-2009400_8852r02

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law;

If you have received this email in error, please notify the sender and
delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.

Thank you.

-- 

Kazuho Oku

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law;

If you have received this email in error, please notify the sender and
delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.

Thank you.

---

From: <[email-masked]>
Date: Thu, 3 Dec 2020 10:13:34 +0000

Hi Mikkel,

that is the decisive question here. I’m convinced, that almost no encapsulated service/transport, where the traffic is split over cellular and Wi-Fi, can cope with the enormous out-of-order delivery due to the latency differences. That means the multipath experience is probably worse compared to traditional singe-path usage. Using datagram frames in the 3GPP scenario does not imply that out-of-order delivery is accepted! That’s why the LS points explicitly to that. Using in-order delivery from QUIC streams will introduce re-transmission, right, that’s why it is not in focus of the LS.

However, I also agree that strict re-ordering is not the solution, since this causes HoL and it’s open how to deal with lost information. So probably it’s time for some smart re-ordering mechanisms here?!

Br

Markus

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Sent: Donnerstag, 3. Dezember 2020 11:01
To: [email-masked]; [email-masked]; Amend, Markus <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

I don’t think it is useful to reorder datagram frames and streams are by definition ordered within a stream and not across streams in QUIC v1 and I don’t see any multipath design that would change that.

If datagram frames were to be ordered, you would loose the ASAP property you want from those frames, and if cross stream ordering is applied, you introduce HoL.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 3 December 2020 at 10.33.17, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:
Full ACK. 3GPP requests MP-QUIC to be applied between UE and UPF. Encapsulating the traffic from services on the UE into this MP-QUIC connection allows communication with the respective remote servers.

Br

Markus

From: Waqar Zia <[email-masked]<mailto:[email-masked]>>
Sent: Donnerstag, 3. Dezember 2020 09:49
To: Jana Iyengar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Apostolis Salkintzis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Amend, Markus <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi Jana,

Best regards,
Waqar.

Thanks!
- jana

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

Thank you.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 3 Dec 2020 03:01:25 -0800

I’d suggest adding a priority scheme: for example only send datagrams on
the low latency path, or only on the slow path, or any path if you want to
maximize resources. If you restrict to one path you get sort-of ordering
without a lot of complexity. You might also want to allow fast path to move
to slow path when there is doubt about link quality, but such that only one
path is used at a time. This does not rule out reordering when switching
path, but a single path can also reorder.

In this way you get the desired profile without all the downsides, except
that you get a lower throughput.

Such a scheme does not need agreement on both ends. It doesn’t even need to
be specified in the protocol. It is an API design issue.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 3 December 2020 at 11.14.10, [email-masked] (
[email-masked]) wrote:

Hi Mikkel,

that is the decisive question here. I’m convinced, that almost no
encapsulated service/transport, where the traffic is split over cellular
and Wi-Fi, can cope with the enormous out-of-order delivery due to the
latency differences. That means the multipath experience is probably worse
compared to traditional singe-path usage. Using datagram frames in the 3GPP
scenario does not imply that out-of-order delivery is accepted! That’s why
the LS points explicitly to that. Using in-order delivery from QUIC streams
will introduce re-transmission, right, that’s why it is not in focus of the
LS.

However, I also agree that strict re-ordering is not the solution, since
this causes HoL and it’s open how to deal with lost information. So
probably it’s time for some smart re-ordering mechanisms here?!

Br

Markus

*From:* Mikkel Fahnøe Jørgensen <[email-masked]>
*Sent:* Donnerstag, 3. Dezember 2020 11:01
*To:* [email-masked]; [email-masked]; Amend, Markus <
[email-masked]>; [email-masked]
*Cc:* [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
*Subject:* RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Kind Regards,

Mikkel Fahnøe Jørgensen

Br

Markus

Hi Jana,

Best regards,

Waqar.

Thanks!

- jana

Hi,

Here is a pdf version.

Regards,

Lionel

Thank you,

Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

-- 

Kazuho Oku

Thank you.

---

From: <[email-masked]>
Date: Thu, 3 Dec 2020 13:09:37 +0000

Hi Mikkel,

I think that is not the intend of the ATSSS “splitting” mode to use more or less single path transmission…

What you propose is from my understanding rather related to the “switching” mode.

Br

Markus

From: QUIC <[email-masked]> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Donnerstag, 3. Dezember 2020 12:01
To: [email-masked]; [email-masked]; Amend, Markus <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

I’d suggest adding a priority scheme: for example only send datagrams on the low latency path, or only on the slow path, or any path if you want to maximize resources. If you restrict to one path you get sort-of ordering without a lot of complexity. You might also want to allow fast path to move to slow path when there is doubt about link quality, but such that only one path is used at a time. This does not rule out reordering when switching path, but a single path can also reorder.

In this way you get the desired profile without all the downsides, except that you get a lower throughput.

Such a scheme does not need agreement on both ends. It doesn’t even need to be specified in the protocol. It is an API design issue.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 3 December 2020 at 11.14.10, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:
Hi Mikkel,

Br

Markus

From: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
Sent: Donnerstag, 3. Dezember 2020 11:01
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Amend, Markus <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Kind Regards,
Mikkel Fahnøe Jørgensen

Br

Markus

Hi Jana,

Best regards,
Waqar.

Thanks!
- jana

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

Thank you.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 3 Dec 2020 17:28:50 +0000

The mere fact that they are ordered, doesn’t imply HoL blocking unless it is used to force in-order delivery.

-=R

From: QUIC <[email-masked]> on behalf of Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thursday, December 3, 2020 at 2:01 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Kind Regards,
Mikkel Fahnøe Jørgensen

Br

Markus

Hi Jana,

Best regards,
Waqar.

Thanks!
- jana

Thanks for raising this topic. With https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-01<https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-01> we consider exactly that and try to provide input to develop/discuss different re-ordering strategies. My personal belief is, that without any re-ordering implementation in the UPF or UE the end-to-end delivery will be worse.

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

On Mon, Nov 30, 2020 at 10:40 PM Liaison Statement Management Tool <[email-masked]<mailto:[email-masked]>> wrote:
Title: LS on ATSSS Phase 2 conclusions
Submission Date: 2020-11-30
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1710/<https://datatracker.ietf.org/liaison/1710/>

Body:
Attachments:

    S2-2009400_8852r02
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-11-30-3gpp-tsgsa-sa2-quic-ls-on-atsss-phase-2-conclusions-attachment-1.doc<https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-11-30-3gpp-tsgsa-sa2-quic-ls-on-atsss-phase-2-conclusions-attachment-1.doc>

Thank you.

--
Kazuho Oku

Thank you.

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 3 Dec 2020 09:58:38 -0800

Thanks for the clarification.

Do I understand correctly that the UE-UPF connection is a multipath tunnel
then? If so, and if ordered delivery is desired, was MPTCP considered as a
solution?

- jana

On Thu, Dec 3, 2020 at 1:32 AM <[email-masked]> wrote:

> Speaking only as a user of computer technology, thanks for making this
> more palatable as a PDF. A few questions:
>
>
>
> - I am a bit confused by the picture, and Spencer or someone else can
> point me to something that I haven't read yet -- I thought the QUIC
> connection was between the remote server and the UE, not between the UPF
> and the UE. Am I missing something?
>

---

From: Apostolis Salkintzis <[email-masked]>
Date: Thu, 3 Dec 2020 18:15:00 +0000

Hi Jana,

Yes, between the UE and UPF there is one multipath tunnel – or several multipath tunnels, each one with different QoS characteristics. Each tunnel should support unreliable transport (e.g. to transfer real-time UDP traffic), so MPTCP is not suitable in this scenario.

BTW, MPTCP between the UE and UPF is already supported in 3GPP Rel-16 specs for TCP traffic.

Regards,
Apostolis

From: Jana Iyengar <[email-masked]>
Sent: Thursday, December 3, 2020 7:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Magnus Westerlund <[email-masked]>; Lars Eggert <[email-masked]>; [email-masked]; Apostolis Salkintzis <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Lucas Pardue <[email-masked]>; Marten Seemann <[email-masked]>; QUIC WG <[email-masked]>; Martin Duke <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: [External] Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Do I understand correctly that the UE-UPF connection is a multipath tunnel then? If so, and if ordered delivery is desired, was MPTCP considered as a solution?

- jana

On Thu, Dec 3, 2020 at 1:32 AM <[email-masked]<mailto:[email-masked]>> wrote:
Full ACK. 3GPP requests MP-QUIC to be applied between UE and UPF. Encapsulating the traffic from services on the UE into this MP-QUIC connection allows communication with the respective remote servers.

Br

Markus

Hi Jana,

Best regards,
Waqar.

Thanks!
- jana

Here is a pdf version.

Regards,

Lionel

Thank you,
Marten

Body:
Attachments:

    S2-2009400_8852r02

Thank you.

--
Kazuho Oku

Thank you.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Dec 2020 15:31:23 -0600

(And, just to add to what Apostolis said)

> BTW, MPTCP between the UE and UPF is already supported in 3GPP Rel-16

One of the goals for post-Rel-16 ATSSS is to support non-TCP traffic.

3GPP ATSSS-LL already supports non-TCP traffic, but it's roughly placed on
whatever outgoing queue to the UPF seems right, delivered in whatever order
the packets arrive at the UPF, etc.

And so, 3GPP hopes to do better than ATSSS-LL, and here we are.

As I understand it. But I'm still not the ATSSS Whisperer[1].

Best,

Spencer

[1] The reference is to a Horse Whisperer -
http://www.careerwithanimals.co.uk/what-does-horse-whisperer-do.html

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Dec 2020 10:17:29 -0600

Hi Jana,

There is a nice overview document on ATSSS that Olivier, et al. wrote:

https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00

Behcet

On Thu, Dec 3, 2020 at 11:59 AM Jana Iyengar <[email-masked]> wrote:

>> *Cc:* [email-masked]; [email-masked];
>> [email-masked]; Apostolis Salkintzis <[email-masked]>;
>> [email-masked]; [email-masked]; Amend, Markus <
>> [email-masked]>; [email-masked]; [email-masked];
>> [email-masked]
>> *Cc:* [email-masked]; [email-masked];
>> [email-masked]; Apostolis Salkintzis <[email-masked]>;
>> [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>> I wonder what this sentence means. Is it suggesting that UPF (and
>> possibly UE) would buffer packets that arrive on the faster path until the
>> packets that were sent on the slower path reach that node? To give an
>> example, let's say that UE has sent three packets: packet 1 sent using
>> WiFi, packet 2 using LTE, packet 3 using WiFi. UPF receives packets in the
>> order of 1, 3, 2. Is UPF expected to postpone the forwarding of packet 3
>> until it receives packet 2?
>>
>> QUIC Discussion List <[email-masked]>; Martin Duke <
>> [email-masked]>
>> [email-masked]>,Magnus Westerlund <
>> [email-masked]>,Lucas Pardue <[email-masked]>,Lars
>> Eggert <[email-masked]>,[email-masked],[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Dec 2020 20:01:43 +0200

Hi,

FYI, below is a draft of our intended response to the recent Liaison Statement "LS on ATSSS Phase 2 conclusions" which we intend to send next week.

Please feel free to send comments.

Thanks,
Lars and Lucas

--

Thank you for the update on your architectural design and your intended standardization timeline.

Multipath support for QUIC remains under active discussion in the IETF QUIC working group. While multiple design proposals for such an extension have been proposed, it remains uncertain for the time being if the WG will come to consensus on adopting a work item on multipath QUIC, and if so, which individual proposal it would be based on and whether or not it would satisfy your architectural design. We unfortunately also cannot predict whether the WG discussion will have sufficiently progressed by March 2021 for such a consensus to emerge.

Kind regards,
Lucas Pardue and Lars Eggert, QUIC Working Group chairs

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 8 Dec 2020 15:06:48 -0600

Hi Lars,

Sorry I did not understand this email and found it very negative.

You mention individual proposals, I saw 4 listed somewhere before. However,
the one by Huitema is not a solution perse (no offense intended) it
addresses one issue it is based on his view that multiple paths should have
one packet numbering.
I thought that deconinck draft was the main one which already has been
revised so many times.

Also I am not sure if it is a good idea to be not so cooperative with a
very important organization like 3GPP.

So I suggest a deep rewrite of this reply.

My 3 cents.

Behcet

On Tue, Dec 8, 2020 at 12:02 PM Lars Eggert <[email-masked]> wrote:

> Hi,
>
> FYI, below is a draft of our intended response to the recent Liaison
> Statement "LS on ATSSS Phase 2 conclusions" which we intend to send next
> week.
>
> Multipath support for QUIC remains under active discussion in the IETF
> QUIC working group. While multiple design proposals for such an extension
> have been proposed, it remains uncertain for the time being if the WG will
> come to consensus on adopting a work item on multipath QUIC, and if so,
> which individual proposal it would be based on and whether or not it would
> satisfy your architectural design. We unfortunately also cannot predict
> whether the WG discussion will have sufficiently progressed by March 2021
> for such a consensus to emerge.
>
> Kind regards,

---

From: Ian Swett <[email-masked]>
Date: Tue, 8 Dec 2020 16:13:49 -0500

> Sorry I did not understand this email and found it very negative.

I would disagree with this characterization.  I believe Lars summary is
realistic and reflects the reality of the discussion I've observed.

>
> You mention individual proposals, I saw 4 listed somewhere before.
> However, the one by Huitema is not a solution perse (no offense intended)
> it addresses one issue it is based on his view that multiple paths should
> have one packet numbering.

I see this as a recurring thread and I don't think that a draft having more
revisions is by itself an indication it should be the primary choice for
adoption.  I think that draft is overly complex as it stands today, but I
agree that having multiple PN spaces is fairly appealing in a general
solution.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 8 Dec 2020 21:24:59 +0000

Hi Behcet,

> I thought that deconinck draft was the main one which already has been

The propose liason statement is based on our understanding of the WG
following the multipath-focused interim meeting and subsequent discussion.
This highlighted different use-cases for multipath and different possible
technical designs. For example, we were presented with Alibaba's use case
which decided not to use the design in draft-deconninck.

That there is more than one possible design, and that there is active
discussion about philosophical design details, is a signal that the WG is
still forming consensus. And we should provide the time needed to explore
these aspects further.

> very important organization like 3GPP.

Consesus is participant driven, we encourage folks to participate in the
QUIC WG and continue the discussion, in line with the guidance Lars
previously sent out.

> So I suggest a deep rewrite of this reply.

We welcome specific suggestions from you or other WG members.

Kind regards
Lucas

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 9 Dec 2020 10:19:46 -0600

Well, I wrote my personal views on the proposed reply.
Was expecting mpquic enthusiasts to speak up, it seems so far no one else
did.

Behcet

---

From: Waqar Zia <[email-masked]>
Date: Thu, 10 Dec 2020 07:57:23 +0000

Thanks Lars, Lucas for the draft reply.

Perhaps we can add one more sentence towards the very end to the effect:

*If there is any further update on this topic, IETF QUIC working group will liaise it to 3GPP.*

...so that 3GPP does not have to keep querying about this.

Thanks,
Waqar.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: 08 December 2020 19:02
To: QUIC WG <[email-masked]>
Subject: Draft response to New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi,

Thanks,
Lars and Lucas

--

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Dec 2020 10:02:55 +0200

> *If there is any further update on this topic, IETF QUIC working group will liaise it to 3GPP.*

Thanks for the suggestion, that is a good addition.

Lars

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 10 Dec 2020 11:43:16 -0800

This is a good response; it reasonably reflects where we are as a working
group.

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Fri, 11 Dec 2020 09:29:46 +0000

Shouldn't the response say something about the expectation of experimentations? 

Bets regards
Hannu

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Waqar Zia
Sent: Thursday, December 10, 2020 9:57 AM
To: Lars Eggert <[email-masked]>; QUIC WG <[email-masked]>
Subject: RE: Draft response to New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Thanks,
Waqar.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: 08 December 2020 19:02
To: QUIC WG <[email-masked]>
Subject: Draft response to New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi,

Thanks,
Lars and Lucas

--

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Dec 2020 11:32:59 +0200

Hi,

> Shouldn't the response say something about the expectation of experimentations?

could you make a text suggestion? It's not fully clear to me what you think we should say.

Thanks,
Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 Dec 2020 12:24:56 -0600

Hi, Lars,

> could you make a text suggestion? It's not fully clear to me what you

I'm not Hannu, so Hannu should answer this, but if you do end up with text
about experimentation in the proposed liaison back, you might point out
that the QUIC working group would appreciate hearing results of
experimentation from people who participate in 3GPP.

We often remind other SDOs that the best way to work IETF is to participate
in IETF working groups (and that's exactly what
https://datatracker.ietf.org/doc/rfc3113/?include_text=1 says explicitly to
3GPP), but saying "and please tell us your experimental results" is
different enough from other ways that other SDOs have worked with the IETF,
that it might be worth saying explicitly.

Do The Right Thing, of course.

Best,

Spencer

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 15 Dec 2020 10:55:01 +0000

Hello Lars and others

How about the following addition below? I know it leaves widely open what kind of experimentations would be helpful. I

Bets regards
Hannu

-------

Multipath support for QUIC remains under active discussion in the IETF QUIC working group. While multiple design proposals for such an extension have been proposed, it remains uncertain for the time being if the WG will come to consensus on adopting a work item on multipath QUIC, and if so, which individual proposal it would be based on and whether or not it would satisfy your architectural design. To help with the selection process we are calling for experimentation results to better understand the design scape options. We unfortunately also cannot predict whether the WG discussion will have sufficiently progressed by March 2021 for such a consensus to emerge.

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Friday, December 11, 2020 8:25 PM
To: Lars Eggert <[email-masked]>
Cc: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; QUIC WG <[email-masked]>; Waqar Zia <[email-masked]>
Subject: Re: Draft response to New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Hi, Lars,

On Fri, Dec 11, 2020 at 3:33 AM Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I'm not Hannu, so Hannu should answer this, but if you do end up with text about experimentation in the proposed liaison back, you might point out that the QUIC working group would appreciate hearing results of experimentation from people who participate in 3GPP.

We often remind other SDOs that the best way to work IETF is to participate in IETF working groups (and that's exactly what https://datatracker.ietf.org/doc/rfc3113/?include_text=1 says explicitly to 3GPP), but saying "and please tell us your experimental results" is different enough from other ways that other SDOs have worked with the IETF, that it might be worth saying explicitly.

Best,

Spencer

Thanks,
Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 15 Dec 2020 14:07:10 -0600

FWIW,

On Tue, Dec 15, 2020 at 4:55 AM Flinck, Hannu (Nokia - FI/Espoo) <
[email-masked]> wrote:

> Hello Lars and others
>
>
>
> How about the following addition below? I know it leaves widely open what
> kind of experimentations would be helpful. I
>
>
>
> Bets regards
>
> Hannu
>
>
>
> -------
>
>
>
> satisfy your architectural design. *To help with the selection process we
> are calling for experimentation results to better understand the design
> scape options. *We unfortunately also cannot predict whether the WG
> discussion will have sufficiently progressed by March 2021 for such a
> consensus to emerge.
>

I think that's fine. Thanks for proposing this text.

Best,

Spencer

> *From:* Spencer Dawkins at IETF <[email-masked]>
>
> *Sent:* Friday, December 11, 2020 8:25 PM
> *To:* Lars Eggert <[email-masked]>
> *Cc:* Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>;
> QUIC WG <[email-masked]>; Waqar Zia <[email-masked]>
> *Subject:* Re: Draft response to New Liaison Statement, "LS on ATSSS
> Phase 2 conclusions"
>
>
>
> Hi, Lars,
>
>
>
> We often remind other SDOs that the best way to work IETF is to
> participate in IETF working groups (and that's exactly what
> https://datatracker.ietf.org/doc/rfc3113/?include_text=1 says explicitly
> to 3GPP), but saying "and please tell us your experimental results" is

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 15 Dec 2020 17:37:54 -0600

Hi Lars,

In the existence of multiple design proposals and seemingly multiple number
of drafts (3 + 1), as I was discussing with Mirja, IETF has a well known
process called

design team

to handle such cases. Why not form a design team and ask them to get a
unified design (and maybe possibly a draft to specify it).

IMHO a design team should be formed immediately, rather than the current
situation whereby different set of individuals discussing important key
design considerations on their own and reaching some conclusions on their
own and putting them in their own drafts.
 Let me finish like my friend Spencer Dawkings does always:
of course do the right thing.

My 3 cents.
Behcet