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