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

[Behcet Sarikaya <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> *Sent:* Donnerstag, 3. Dezember 2020 09:49
>> *To:* Jana Iyengar <[e-mail]>; [e-mail]
>> *Cc:* [e-mail]; [e-mail];
>> [e-mail]; Apostolis Salkintzis <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; Amend, Markus <
>> [e-mail]>; [e-mail]; [e-mail];
>> [e-mail]
>> *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 <[e-mail]> *On Behalf Of *Jana Iyengar
>> *Sent:* 03 December 2020 05:55
>> *To:* [e-mail]
>> *Cc:* [e-mail]; [e-mail];
>> [e-mail]; Apostolis Salkintzis <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> *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 <[e-mail]> wrote:
>>
>> Including Apostolis into the loop.
>>
>>
>>
>> *De :* [e-mail] [mailto:[e-mail]]
>> *Envoyé :* mardi 1 décembre 2020 12:07
>> *À :* [e-mail]; MORAND Lionel TGI/OLN <
>> [e-mail]>
>> *Cc :* [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> *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 <[e-mail]> *On Behalf Of *Kazuho Oku
>> *Sent:* Dienstag, 1. Dezember 2020 11:29
>> *To:* [e-mail]
>> *Cc:* Magnus Westerlund <[e-mail]>; Liaison
>> Statement Management Tool <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail];
>> Lucas Pardue <[e-mail]>; Marten Seemann <
>> [e-mail]>; Lars Eggert <[e-mail]>; QUIC Discussion
>> List <[e-mail]>; Martin Duke <[e-mail]>
>> *Subject:* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
>>
>>
>>
>> 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 <[e-mail]>:
>>
>> Hi,
>>
>>
>>
>> Here is a pdf version.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Lionel
>>
>>
>>
>> *De :* Marten Seemann [mailto:[e-mail]]
>> *Envoyé :* mardi 1 décembre 2020 05:17
>> *À :* Liaison Statement Management Tool <[e-mail]>
>> *Cc :* Lucas Pardue <[e-mail]>; Lars Eggert <
>> [e-mail]>; Magnus Westerlund <[e-mail]>;
>> MORAND Lionel TGI/OLN <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail];
>> QUIC Discussion List <[e-mail]>; Martin Duke <
>> [e-mail]>
>> *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 <
>> [e-mail]> 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 <[e-mail]>
>> To: Lars Eggert <[e-mail]>,Lucas Pardue <
>> [e-mail]>
>> Cc: QUIC Discussion List <[e-mail]>,Martin Duke <
>> [e-mail]>,Magnus Westerlund <
>> [e-mail]>,Lucas Pardue <[e-mail]>,Lars
>> Eggert <[e-mail]>,[e-mail],[e-mail]
>> Response Contacts: [e-mail],[e-mail]
>> 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
>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>>
>>
>> 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.
>>
>>
>>
>> --
>>
>> 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;
>>
>> 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.
>>
>>