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