Hi Mikkel, I think that is not the intend of the ATSSS “splitting” mode to use more or less single path transmission…
What you propose is from my understanding rather related to the “switching” mode. Br Markus From: QUIC <[email protected]> On Behalf Of Mikkel Fahnøe Jørgensen Sent: Donnerstag, 3. Dezember 2020 12:01 To: [email protected]; [email protected]; Amend, Markus <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [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" I’d suggest adding a priority scheme: for example only send datagrams on the low latency path, or only on the slow path, or any path if you want to maximize resources. If you restrict to one path you get sort-of ordering without a lot of complexity. You might also want to allow fast path to move to slow path when there is doubt about link quality, but such that only one path is used at a time. This does not rule out reordering when switching path, but a single path can also reorder. In this way you get the desired profile without all the downsides, except that you get a lower throughput. Such a scheme does not need agreement on both ends. It doesn’t even need to be specified in the protocol. It is an API design issue. Kind Regards, Mikkel Fahnøe Jørgensen On 3 December 2020 at 11.14.10, [email protected]<mailto:[email protected]> ([email protected]<mailto:[email protected]>) wrote: Hi Mikkel, that is the decisive question here. I’m convinced, that almost no encapsulated service/transport, where the traffic is split over cellular and Wi-Fi, can cope with the enormous out-of-order delivery due to the latency differences. That means the multipath experience is probably worse compared to traditional singe-path usage. Using datagram frames in the 3GPP scenario does not imply that out-of-order delivery is accepted! That’s why the LS points explicitly to that. Using in-order delivery from QUIC streams will introduce re-transmission, right, that’s why it is not in focus of the LS. However, I also agree that strict re-ordering is not the solution, since this causes HoL and it’s open how to deal with lost information. So probably it’s time for some smart re-ordering mechanisms here?! Br Markus From: Mikkel Fahnøe Jørgensen <[email protected]<mailto:[email protected]>> Sent: Donnerstag, 3. Dezember 2020 11:01 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Amend, Markus <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions" Are the special ordering concerns beyond single streams? I don’t think it is useful to reorder datagram frames and streams are by definition ordered within a stream and not across streams in QUIC v1 and I don’t see any multipath design that would change that. If datagram frames were to be ordered, you would loose the ASAP property you want from those frames, and if cross stream ordering is applied, you introduce HoL. Kind Regards, Mikkel Fahnøe Jørgensen On 3 December 2020 at 10.33.17, [email protected]<mailto:[email protected]> ([email protected]<mailto:[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]<mailto:[email protected]>> Sent: Donnerstag, 3. Dezember 2020 09:49 To: Jana Iyengar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Apostolis Salkintzis <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Amend, Markus <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf Of Jana Iyengar Sent: 03 December 2020 05:55 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Apostolis Salkintzis <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]>> wrote: Including Apostolis into the loop. De : [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] Envoyé : mardi 1 décembre 2020 12:07 À : [email protected]<mailto:[email protected]>; MORAND Lionel TGI/OLN <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf Of Kazuho Oku Sent: Dienstag, 1. Dezember 2020 11:29 To: [email protected]<mailto:[email protected]> Cc: Magnus Westerlund <[email protected]<mailto:[email protected]>>; Liaison Statement Management Tool <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Lucas Pardue <[email protected]<mailto:[email protected]>>; Marten Seemann <[email protected]<mailto:[email protected]>>; Lars Eggert <[email protected]<mailto:[email protected]>>; QUIC Discussion List <[email protected]<mailto:[email protected]>>; Martin Duke <[email protected]<mailto:[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]<mailto:[email protected]>>: Hi, Here is a pdf version. Regards, Lionel De : Marten Seemann [mailto:[email protected]<mailto:[email protected]>] Envoyé : mardi 1 décembre 2020 05:17 À : Liaison Statement Management Tool <[email protected]<mailto:[email protected]>> Cc : Lucas Pardue <[email protected]<mailto:[email protected]>>; Lars Eggert <[email protected]<mailto:[email protected]>>; Magnus Westerlund <[email protected]<mailto:[email protected]>>; MORAND Lionel TGI/OLN <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; QUIC Discussion List <[email protected]<mailto:[email protected]>>; Martin Duke <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> To: Lars Eggert <[email protected]<mailto:[email protected]>>,Lucas Pardue <[email protected]<mailto:[email protected]>> Cc: QUIC Discussion List <[email protected]<mailto:[email protected]>>,Martin Duke <[email protected]<mailto:[email protected]>>,Magnus Westerlund <[email protected]<mailto:[email protected]>>,Lucas Pardue <[email protected]<mailto:[email protected]>>,Lars Eggert <[email protected]<mailto:[email protected]>>,[email protected]<mailto:[email protected]>,[email protected]<mailto:[email protected]> Response Contacts: [email protected]<mailto:[email protected]>,[email protected]<mailto:[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.
