Subject: [QUIC] Scope of multi-path WAS: Re: Draft charter

From: Göran Eriksson AP <[email-masked]>
Date: Sun, 15 May 2016 10:00:41 +0000

>
>
>
>
>It would be great to have some of the discussion on the list before the
>BoF.  

Hi!

Have a question concerning the scope of “multi-path” work:

The full area of multi-path is rather big, especially if combined with
mobility and the possibility to migrate some but not all flows the
“application” using a “rich API” to provide hints to the transport middle
ware.

The current charter text is not so precise on the scope and ambition on
multi-path.

Is the scope perhaps implicitly limited to existing multi-path TCP
realisation/usage?

Regards
Göran

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 May 2016 09:00:25 -0700

Hi Göran,

The thinking was to cover the functional equivalent of SCTP or MPTCP
multipath, which is a relatively known scope in the IETF context. I'm happy
to add more text if folks think that being more explicit here is useful.

- jana

On Sun, May 15, 2016 at 3:00 AM, Göran Eriksson AP <
[email-masked]> wrote:

> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Mon, 16 May 2016 21:40:05 +0000

>multipath, which is a relatively known scope in the IETF context. I'm
>happy to add more text if folks think that being more explicit here is
>useful.

Hi Jana,

Sounds like a good scope for a focused first phase. There may be some use
cases for HTTP/2 in a multi-homed device that goes beyond the current
MPTCP implementations but let me get back on that one later (need to
noodle that problem some more).

Personally leaning towards also describing the scope in text but I am open
to other views, :-).

And as we refer to SCTP and MPTCP, then possibly API considerations should
be a deliverable as well as these are available for MPTCP if I am not
mistaken (RFC6897 right?).

Best regards
Göran

PS. Charter text is good. Not considering the multi-path question a major
issue.

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 16 May 2016 23:57:49 +0200

Goran,
> mistaken (RFC6897 right?).

Well, although the title of RFC6897 contains the word API, it is very 
minimalist and cannot be considered as an API that allows to control 
MPTCP. If RFC6897 is used as an example to specify an API for QUIC, then 
it means that the WG will not really produce an API...

If QUIC focuses on the HTTP/2 like use case, I'm not sure that an API 
would be required. Maybe some QUIC parameters could be exposed and 
possibly tuned by the applications using QUIC.

Olivier

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 20 May 2016 15:54:33 -0700

On Mon, May 16, 2016 at 2:57 PM, Olivier Bonaventure <
[email-masked]> wrote:

> minimalist and cannot be considered as an API that allows to control MPTCP.
> If RFC6897 is used as an example to specify an API for QUIC, then it means
> that the WG will not really produce an API...
>
> would be required. Maybe some QUIC parameters could be exposed and possibly
> tuned by the applications using QUIC.

I agree. At this point, it's not clear to me how useful a QUIC API doc will
be. We can certainly consider it later as more implementations emerge.

- jana

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 20 May 2016 23:34:13 +0000

>I agree. At this point, it's not clear to me how useful a QUIC API doc
>will be. We can certainly consider it later as more implementations
>emerge.

+1

But perhaps you could elaborate a bit on the use of MPQUIC case/usages you
are considering?

Mobility? And if you foresee any case where the path selection will be
done based on http layer input?

Regards
Göran

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 15:08:14 -0700

Göran,

I am adding text to the charter to say that both reliability (mobility) and
load sharing will be in scope for multipath. Path selection will probably
be left to implementations, just as it is in SCTP and MPTCP.

- jana

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 26 May 2016 09:22:49 +0000

Hi Jana,

I think I agree with you on what the charter should say on this topic.

Just a clarification about why you put mobility in brackets in your answer below.
Do you see reliability in Quic as something only for mobility
while the default usage of multipath would be load sharing?

About Path selection while I tend to agree that most likely it is better to leave it to implementation,
I think that there should be at least some consideration and suggestion on path management
Having said that I don’t think the Charter should go into the detail of Path selection

/Sal

From: QUIC [mailto:[email-masked]] On Behalf Of Jana Iyengar
Sent: den 24 maj 2016 00:08
To: Göran Eriksson AP <[email-masked]>
Cc: Christian Huitema <[email-masked]>; Olivier Bonaventure <[email-masked]>; [email-masked]; Ted Hardie <[email-masked]>
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter

Göran,

I am adding text to the charter to say that both reliability (mobility) and load sharing will be in scope for multipath. Path selection will probably be left to implementations, just as it is in SCTP and MPTCP.

- jana

+1

Regards
Göran

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 27 May 2016 18:26:13 -0700

Thanks Sal. To clarify, I meant to say use the term reliability to mean
mobility, but it's definitely unnecessarily confusing. I'll use just
"mobility" instead.

- jana

On Thu, May 26, 2016 at 2:22 AM, Salvatore Loreto <
[email-masked]> wrote:

> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Jana Iyengar
> *Sent:* den 24 maj 2016 00:08
> *To:* Göran Eriksson AP <[email-masked]>
> *Cc:* Christian Huitema <[email-masked]>; Olivier Bonaventure <
> [email-masked]>; [email-masked]; Ted Hardie <
> [email-masked]>
> *Subject:* Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
>
>
>
> Göran,
>
>
>
> I am adding text to the charter to say that both reliability (mobility)
> and load sharing will be in scope for multipath. Path selection will
> probably be left to implementations, just as it is in SCTP and MPTCP.
>
>
>
> - jana
>
>
>