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