Subject: [multipathtcp] Summary for discussions on potential MPTCP proxy work

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 15 Jun 2017 11:03:48 -0700

Thank you for the replies and discussion about the consensus call and
active discussions on this topic. We apologize for the delay in responding.
We have discussed and studies this topic carefully.

In our observation, we believe most people basically support proxy work in
the WG along with #1 scenario in page 12 at https://www.ietf.org/
proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf

OTOH, we've seen some folks raised concerns on the proposal.

The chairs have discussed on these concerns and we think the following
points will not be solved in the current proposal without significant
updates.

    a) The current proposal requires applications to snoop transit traffics
and modify header information in TCP packets.

    b) The current proposal requires to convey information in TCP SYN
packets. This would need to consider cooperation with other WGs, such as
tcpm or tsvwg, to consider any impact on the robustness and security of TCP.

    c) The current document is hard for people to understand the proposal

Based on our assessment of the current situation, we think some combination
of the followings will be required in order to make progress.

    -   A new draft, based on the existing one but with modifications to
address the concerns

    -   A fresh approach

    -   A possible update of some of our technology criteria. For example,
we've seen some people prefer 0-RTT approach, but this might be a bit hard
requirement and 1 or 2 RTTs could be possible compromise.

Again, we appreciate lots of productive discussions and very sorry for our
slow response.

If you have comments or questions on our current assessments, please let us
know.

Best regards,

--

Yoshi & Phil

---

From: <[email-masked]>
Date: Fri, 16 Jun 2017 12:56:04 +0000

Hi Yoshi,

Thank you for this summary that I read as a confirmation of the consensus to work on #1 as per the outcome of the last IETF meeting.

I don’t quite understand why the WG should wait for yet another cycle before adopting the document. Sure, the document needs to be updated to reflect some of outcomes of the discussion and other inputs from the WG. That’s just the normal IETF process.

I’m afraid there may be confusion between a WGLC and a document adoption call.

Having a WG item ASAP will help us fixing issues that are raised or yet-to-be raised.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Yoshifumi Nishida
Envoyé : jeudi 15 juin 2017 20:04
À : multipathtcp
Objet : [multipathtcp] Summary for discussions on potential MPTCP proxy work

Thank you for the replies and discussion about the consensus call and active discussions on this topic. We apologize for the delay in responding. We have discussed and studies this topic carefully.

In our observation, we believe most people basically support proxy work in the WG along with #1 scenario in page 12 at https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf

The chairs have discussed on these concerns and we think the following points will not be solved in the current proposal without significant updates.

    a) The current proposal requires applications to snoop transit traffics and modify header information in TCP packets.

    b) The current proposal requires to convey information in TCP SYN packets. This would need to consider cooperation with other WGs, such as tcpm or tsvwg, to consider any impact on the robustness and security of TCP.

Based on our assessment of the current situation, we think some combination of the followings will be required in order to make progress.

    -   A new draft, based on the existing one but with modifications to address the concerns
    -   A fresh approach
    -   A possible update of some of our technology criteria. For example, we've seen some people prefer 0-RTT approach, but this might be a bit hard requirement and 1 or 2 RTTs could be possible compromise.

Again, we appreciate lots of productive discussions and very sorry for our slow response.
If you have comments or questions on our current assessments, please let us know.

Best regards,
--
Yoshi & Phil

---

From: <[email-masked]>
Date: Fri, 16 Jun 2017 14:02:26 +0000

WG,

I am too a bit unclear about some of the text of Yoshi’s message.

Like Med, I would like to read it as a confirmation that the proxy work based upon option #1 that was discussed during the Chicago session and which reached consensus among the WG members is now an mptcp WG item.

Then, the “the current document is hard for people to understand the proposal” argument reads very speculative to me and I don’t believe this is actually an argument per se.

And there’s the notion of “fresh approach” that may be possibly combined with one of the other options listed in Yoshi’s message, which I don’t quite understand from a working procedure standpoint.

We have a document on the table. Let us work on it to address all the concerns that have been raised so far and those that may arise as we progress the discussion, like any other typical IETF WG specification effort.

I’m looking forward to working with you all.

Cheers,

Christian.

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 16 juin 2017 14:56
À : Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] Summary for discussions on potential MPTCP proxy work

Hi Yoshi,

Cheers,
Med

Best regards,
--
Yoshi & Phil

_________________________________________________________________________________________________________________________

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.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 16 Jun 2017 12:04:26 -0700

Hi Med, Christian,

Thanks for the response. I think I understand your point.
But, one thing I would like to mention is that our consensus can be
archived when all issues are addressed. (see rfc7282)
We don't think we have found good counter arguments to address or push away
the concerns raised during discussions.
So, we decide not to adopt the current proposal for now as we think just
counting number of support/unsupport won't be good way to measure consensus
here.

Also, as we know we have quite lengthy discussions on this draft.
But, I am not very sure if it is getting matured and not sure if we can
implement it by just reading the draft.
We start having big concerns how long it will take to publish it.

That's why the chairs think some drastic changes will be necessary. We are
afraid that if we try to update the draft incrementally, we might need to
spend another a year or so for discussions. We thought it will be much
shorter if we do a fresh start based on what we have learned so far.

Anyway, our common purpose is to explore a simple, straightforward and
well-focused and implementable proposal on this topic.
If you have some ideas to reach this goal, please share. Phil and I are
discussing what's the best options for the WG.

Thanks,
--
Yoshi

On Fri, Jun 16, 2017 at 7:02 AM, <[email-masked]> wrote:

> Like Med, I would like to read it as a confirmation that the proxy work
> based upon option #1 that was discussed during the Chicago session and
> which reached consensus among the WG members is now an mptcp WG item.
>
>
>
> Then, the “the current document is hard for people to understand the
> proposal” argument reads very speculative to me and I don’t believe this is
> actually an argument per se.
>
>
>
> And there’s the notion of “fresh approach” that may be possibly combined
> with one of the other options listed in Yoshi’s message, which I don’t
> quite understand from a working procedure standpoint.
>
>
>
> We have a document on the table. Let us work on it to address all the
> concerns that have been raised so far and those that may arise as we
> progress the discussion, like any other typical IETF WG specification
> effort.
>
>
>
> *De :* multipathtcp [mailto:[email-masked]] *De la part de*
> [email-masked]
> *Envoyé :* vendredi 16 juin 2017 14:56
> *À :* Yoshifumi Nishida; multipathtcp
> *Objet :* Re: [multipathtcp] Summary for discussions on potential MPTCP
> proxy work
>
>
>
> Hi Yoshi,
>
>
>
> Thank you for this summary that I read as a confirmation of the consensus
> to work on #1 as per the outcome of the last IETF meeting.
>
>
>
> I don’t quite understand why the WG should wait for yet another cycle
> before adopting the document. Sure, the document needs to be updated to
> reflect some of outcomes of the discussion and other inputs from the WG.
> That’s just the normal IETF process.
>
>
>
> *De :* multipathtcp [mailto:[email-masked]
> <[email-masked]>] *De la part de* Yoshifumi Nishida
> *Envoyé :* jeudi 15 juin 2017 20:04
> *À :* multipathtcp
> *Objet :* [multipathtcp] Summary for discussions on potential MPTCP proxy
> work
>
>
>
> the WG along with #1 scenario in page 12 at https://www.ietf.org/procee
> dings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf
>
>
>
>     a) The current proposal requires applications to snoop transit
> traffics and modify header information in TCP packets.
>
>
>
> Based on our assessment of the current situation, we think some
> combination of the followings will be required in order to make progress.
>
>
>

---

From: <[email-masked]>
Date: Thu, 22 Jun 2017 09:22:41 +0000

Hi Yoshi,

Thank you for clarifying.

One thing that will be really helpful is to summarize the issues that you (chairs) think are not clarified during the discussion.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : vendredi 16 juin 2017 21:04
À : JACQUENET Christian IMT/OLN
Cc : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] Summary for discussions on potential MPTCP proxy work

Hi Med, Christian,

Thanks for the response. I think I understand your point.
But, one thing I would like to mention is that our consensus can be archived when all issues are addressed. (see rfc7282)
We don't think we have found good counter arguments to address or push away the concerns raised during discussions.
So, we decide not to adopt the current proposal for now as we think just counting number of support/unsupport won't be good way to measure consensus here.

Also, as we know we have quite lengthy discussions on this draft.
But, I am not very sure if it is getting matured and not sure if we can implement it by just reading the draft.
We start having big concerns how long it will take to publish it.

That's why the chairs think some drastic changes will be necessary. We are afraid that if we try to update the draft incrementally, we might need to spend another a year or so for discussions. We thought it will be much shorter if we do a fresh start based on what we have learned so far.

Anyway, our common purpose is to explore a simple, straightforward and well-focused and implementable proposal on this topic.
If you have some ideas to reach this goal, please share. Phil and I are discussing what's the best options for the WG.

Thanks,
--
Yoshi

On Fri, Jun 16, 2017 at 7:02 AM, <[email-masked]<mailto:[email-masked]>> wrote:
WG,

Cheers,

Christian.

De : multipathtcp [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : vendredi 16 juin 2017 14:56
À : Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] Summary for discussions on potential MPTCP proxy work

Hi Yoshi,

Cheers,
Med

Best regards,
--
Yoshi & Phil

Thank you.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 23 Jun 2017 01:23:59 -0700

Hi Med,

On Thu, Jun 22, 2017 at 2:22 AM, <[email-masked]> wrote:

> One thing that will be really helpful is to summarize the issues that you
> (chairs) think are not clarified during the discussion.
>

I believe it would be good if we can have simple architecture rather than
complex one.
If we have to have a complex architecture, I think we will need
technological justifications for the complexities to make people convince
it's worth for the price.

For example, in order to do a) in the previous mail, the proposal requires
complex architecture and some layer violations. But, we haven't seen strong
justification for it.
I think this is mainly for 0-RTT requirement. But, it is still unclear that
it's worth for the price or 0-RTT is absolutely necessary.
I hope this will explain our points to some extents.

--
Yoshi

>
>
> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* vendredi 16 juin 2017 21:04
> *À :* JACQUENET Christian IMT/OLN
> *Cc :* BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida; multipathtcp
>
> We don't think we have found good counter arguments to address or push
> away the concerns raised during discussions.
>

---

From: <[email-masked]>
Date: Fri, 23 Jun 2017 08:47:50 +0000

Hi Yoshi,

Thank you.

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : vendredi 23 juin 2017 10:24
À : BOUCADAIR Mohamed IMT/OLN
Cc : Yoshifumi Nishida; JACQUENET Christian IMT/OLN; multipathtcp
Objet : Re: [multipathtcp] Summary for discussions on potential MPTCP proxy work

Hi Med,

On Thu, Jun 22, 2017 at 2:22 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

I believe it would be good if we can have simple architecture rather than complex one.
[Med] I don’t think the proposed architecture is complex. It is quite simple :

·         One single in-band signal message; no change to subsequent messages.

·         Re-use the same functions for rewriting packets as in SOCKS and leverage on existing IETF standards (e.g., RFC 7857).

·         Do not require any change to the base MPTCP.

If we have to have a complex architecture, I think we will need technological justifications for the complexities to make people convince it's worth for the price.
[Med] I still don’t get the “complexities” you are referring to. That’s said, given the clear consensus during the last IETF meeting that the WG wants to work on this proposal.

For example, in order to do a) in the previous mail, the proposal requires complex architecture and some layer violations. But, we haven't seen strong justification for it.
[Med] Can you please explicit those “violationS”?

I think this is mainly for 0-RTT requirement. But, it is still unclear that it's worth for the price or 0-RTT is absolutely necessary.
[Med] There was a strong agreement in the WG that 0-RTT is a key requirement. I don’t see why we should requisition what was agreed by the WG.

I hope this will explain our points to some extents.
[Med] Sorry, but I’m afraid not.

--
Yoshi

De : Yoshifumi Nishida [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 16 juin 2017 21:04
À : JACQUENET Christian IMT/OLN
Cc : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida; multipathtcp

Hi Med, Christian,

Thanks,
--
Yoshi

Cheers,

Christian.

Hi Yoshi,

Cheers,
Med

Best regards,
--
Yoshi & Phil

Thank you.