Subject: Uploaded combined slides on Multipath in ATSSS

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Oct 2020 13:18:00 -0500

Dear Chairs,

You should have https://github.com/quicwg/wg-materials/pull/163 available
for your viewing pleasure :-)

Best,

Spencer

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 21 Oct 2020 11:13:47 +0900

Hello,

Thank you for working on the slides and sharing them beforehand. They gave
mea  good understanding on what the requirements from ATSSS would be.

I have one question: Regarding feature breakdown in pp. 7-8, would it be
the case that the server address can be stable throughout the lifetime of a
QUIC connection for all the bullet points? Or would it be the case that the
server has to migrate to a different address mid-connection?

What I am wondering is if path validation scheme that we have in QUICv1
would be sufficient for supporting ATSSS, or if simultaneous migration
would be required.

I think that having that point clarified (possibly during the presentation)
would help us better understand the amount of work we need to devote if we
decide to design features necessary for ATSSS.

Thank you in advance.

-- 
Kazuho Oku

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Oct 2020 23:36:56 -0500

Hi, Kazuho,

> server has to migrate to a different address mid-connection?

(When you say "server", you mean "the other end of the QUIC connection",
right? That's often a UPF, which could be something like a MASQUE server in
some eATSSS proposals)

I don't think the "other end of the QUIC connection" is likely to change
its addresses - the UE is the mobile part of eATSSS, and even then, 3GPP
networks use GTP tunneling to handle mobility, so the UE addresses don't
need to change.

But I'm not sure everyone would agree about that.

> I think that having that point clarified (possibly during the
> presentation) would help us better understand the amount of work we need to
> devote if we decide to design features necessary for ATSSS.
>

I agree that's a good question to talk about in discussion. I haven't seen
concerns expressed about that, but people are still thinking through the
details.

And thank you for raising the question!

Best,

Spencer

Thank you in advance.
>
> 2020年10月21日(水) 3:18 Spencer Dawkins at IETF <[email-masked]
> >:
>
>> Dear Chairs,
>>
>> You should have https://github.com/quicwg/wg-materials/pull/163
>> available for your viewing pleasure :-)
>>
>> Best,
>>
>> Spencer
>>
>
>
> --
> Kazuho Oku
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 21 Oct 2020 07:13:47 -0500

Dear Chairs,

> for your viewing pleasure :-)

I've uploaded a minor revision to Github, to reflect three minor comments
from co-authors. I will now sit quietly with my hands folded until the
meeting tomorrow.

Just to confirm - Spencer and Florin both had 5+5 speaking slots on the
agenda, but our intention is to do this in one 5+5 speaking slot (so you
get 10 minutes back for general discussion).

And thanks for your helpful suggestions. They improved the presentation
quite a bit.

Best,

Spencer

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Oct 2020 08:51:58 +0900

Hi, Spencer,

Thank you for your quick answer.

The reason I asked if ATSSS requires changes to path migration is because
path validation on an encrypted transport protocol is complicated. One of
the requirements that is unique to path migration of QUIC is that it has to
be tolerant against MOTS attacks.

I think that the WG has, after some back and forth, come to a sensible
design, but it has not been tested in the wild yet. Therefore trying to
extend path migration might be a bit risky at this point.

Also, because there are security requirements for path migration, we do not
have the option to delegate the responsibility of doing the correct thing
to the implementations.

Compared to that, sending data simultaneously on multiple paths do not have
security concerns (or they are comparably minor), and we (as a WG that
designs the protocol) can delegate many design choices to implementations.

Just my thoughts.

2020年10月21日(水) 13:37 Spencer Dawkins at IETF <[email-masked]

>> Thank you for working on the slides and sharing them beforehand. They
>> gave mea  good understanding on what the requirements from ATSSS would be.
>>

-- 
Kazuho Oku