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

[Jana Iyengar <[e-mail]>]

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