Please provide a brief description for a proposed table of contents for the draft

So far, look for contributions from Anna, Andreas, Markus, Spencer, Stephen, Qing, Olivier and Nicolas - please add your name if you're typing here!

Abstract

Introduction

(Stephen: I think the intro should include operator motivation and requirements for ATSSS. This probably covers some of the "What ATSSS is intended to do" section. The operator motivation is largely to have the ability to deliver the best possible user experience to the end customer by using both the fixed and mobile access networks. The requirements are driven by the two primary operator use cases: fixed hybrid access for the residential gateway and the nomadic mobile device. The main requirements are: failover, boosted throughput (i.e. topping up the operator's preferred access with capacity from the secondary access to achieve the desired throughput), and fast seamless handover for real time services)

(Olivier: although fixed hybrid access is a clear use case as well, it is not exactly ATSSS. Adding this makes the document more general, but also increases the risk of considering it too complex by IETF)

(Markus: Agree to limit to the ATSSS use case, since the BBF adopts ATSSS for Hybrid Access purposes. However, mentioning this BBF adoption shortly in the introduction is certainly not wrong and makes IETF aware that there is a scope beyond the pure 3GPP use case.)

(Spencer: I would agree with that plan).

Concept and terminology (Addition suggested by Andreas)

(Andreas: start with terminology that defines terms later used, and the main concepts. Then we can go in the details of what Reliable 16 and Reliable 17 puts in following separate sections, which can be parts of what Anna proposed)

(Spencer: Yes, although I hope there aren't a lot of terms. My opinion is, the more this draft maps onto the 5G architecture, the less successful we would be in explaining it to the IETF)

(Olivier: I would suggest to only define one term: ATSSS and then use as much IETF terminology and map to IETF protocols by considering simple examples. Having a long list of acronyms would encourage the readers to stop reading the document)

High level overview of ATSSS (Addition suggested by Anna)

(Anna: I suggest to start with a high level overview of ATSSS and then go into the functionality in Release 16 and the target for Release 17. This high level overview may also be done as introductory text if we choose to make the Rel16, use of MPTCP and Rel17 parts subsections.)

(Spencer would agree with this, but again, it's going to be really important that we don't explain too much - and explaining differences between Rel16 and Rel17 would likely be "too much" for IETF people who don't follow 3GPP. So I'd explain Rel17 as practiced today, if that's our baseline)

(Olivier: I would suggest to limit the different between R16 and R17 as follows:

• R16 only supports TCP using proxies with an IETF protocol
• R17 will carry TCP, UDP and plain IP This would be understandable by IETFers)

What ATSSS is intended to do (in Release 16?)

(Spencer believes the scope of ATSSS is a lot more limited than "sharing bandwidth appropriately across multiple arbitrary paths", which is probably what's driving the people in QUIC who are worried about general multipath solutions)

(Markus: An important fact of ATSSS and Hybrid Access architecture is, that MP protocols are not implemented E2E, rather they are terminated between UE/RG and operator network. MPTCP in this respect is easy to handle, since it can be terminated/converted by a TCP proxy. (MP-)QUIC put the challenge that it is intended to work E2E, without any opportunity to intercept in between.

(Spencer - yes, that will be key. It's worth asking now, if this is the only challenge we see to using (MP-)QUIC. )

(Markus: No, please look into reference 1.ii and https://mailarchive.ietf.org/arch/msg/quic/M4ftdooSOhloQcnqyx8oagZpRe0/. I assume that we talk about transporting QUIC (or generic UDP traffic) over a MP-QUIC managed tunnel between UE/RG and UPF, which is a direct consequence of above mentioned QUIC's e2e encryption. This leads to further implications/needs:

• Multiple encryption layer (ATSSS IPsec for 3GPP untrusted path, MP-QUIC tunnel, QUIC; Currently discussed in the MASQUE context)
• CC over CC
• Unreliable QUIC for the tunnel to avoid reliability over reliability respectively latency issues?! -> Datagram support within QUIC
• Reassembly of a Datagram MP-QUIC stream on the receiver side -> Proper re-ordering algorithms specified e.g. in something similar like https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers. Maybe also in combination with QUIC-FEC. )

(Olivier: I would focus on explaining simple scenarios

• use two paths to transport one plain IP flow with switching initially and splitting later
• use two paths to transport one TCP connection with switching initially and splitting later steering is something which is related to policies and needs to be handled by 3GPP without too much input from IETF)

(Nicolas: What about non-IP? The ATSSS-LL is supposed to cover Ethernet traffic. Could it be also tunneled into MPQUIC?)

(Olivier: We can add Ethernet, this would be acceptable by IETF)

ATSSS Requirements

(Andreas: Here can be the list of requirements that are analysed based on the Concept and ATSSS architecture.)

How ATSSS uses MP-TCP

(Anna: I assume this should still refer to Release 16. I suggest to make this clear in the title or it could be a subsection of the one above.)

(Spencer: definitely, make that clear in the title)

(Spencer: my suggestion is that we do not include requirements in this draft - especially not at first. We have too many engineers who will focus on what the requirements should be with an incomplete understanding of ATSSS. I agree with doing requirements work, if we can do that without a couple of formal liaison cycles (9-12 months) confirming that these are "really the 3GPP requirements" - we don't have to wait for an IETF meeting to ask, but I'm pretty sure they have to wait for a 3GPP meeting to answer)

(Stephen: Somewhere we need to cover the fact that ATSSS has two multipath delivery frameworks: MPTCP and ATSSS-LL. Rel 17 is trying to identify a solution that covers use cases that cannot be satisfied by either of these frameworks)

(Spencer: that seems very important to say in the concepts material)

What ATSSS extensions are targeted in Release 17 (Addition suggested by Anna)

(Spencer: I think this is also important in the concepts material)

What problems 3GPP is encountering using MP-TCP

(Spencer: Are any of these problems unique to 3GPP usage in ATSSS?)

(Anna: Perhaps phrase title as limitations rather than problems.)

(Spencer: I agree)

(Anna: This should be tied to the target for Release 17 and the requirements that poses.)

(Spencer: I agree, and if people are OK not including requirements in -00, or including them in a separate draft, this is in the right place - otherwise, requirements needs to follow this material)

Existing MP capable IETF protocols compared to ATSSS Rel. 17 requirements

(Markus: Compare existing protocols, e.g. MPTCP, MP-QUIC, CMT-SCTP, MP-DCCP with the ATSSS requirements to either strengthen a MP-QUIC solution and/or find (interim) alternatives.

What can QUIC do to solve the 3GPP problems

(Qing: suggest to add a section describing what QUIC needs to do in order to solve the problems 3GPP is encountering using MP-TCP, to give IETF a clear target)

(Markus: Will be most probably the fact, that MPTCP does not support any traffic than TCP efficiently?! Compare reference 1.ii, Slide 3)

(Olivier: agreed, this is the main motivation to add MPQUIC and datagram support is well accepted within the quic WG)