Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work

From: <[email-masked]>
Date: Tue, 2 May 2017 08:40:14 +0000

Hi Juliusz, 

Yes, that's the point. 

We are leveraging on existing IETF endorsed behaviors (defined in BCPs). In particular, we are assuming this simplified state machine by the proxy: 

                    +----------------------------+
                    |                            |
                    V                            |
                 +------+   Client               |
                 |CLOSED|-----SYN------+         |
                 +------+              |         |
                     ^                 |         |
                     |TCP_TRANS T.O.   |         |
                     |                 V         |
                 +-------+          +-------+    |
                 | TRANS |          |  INIT |    |
                 +-------+          +-------+    |
                   |    ^               |        |
             data pkt   |               |        |
                   | Server/Client RST  |        |
                   |  TCP_EST T.O.      |        |
                   V    |           Server SYN   |
              +--------------+          |        |
              | ESTABLISHED  |<---------+        |
              +--------------+                   |
               |           |                     |
         Client FIN    Server FIN                |
               |           |                     |
               V           V                     |
        +---------+   +----------+               |
        |  C FIN  |   |  S FIN   |               |
        |   RCV   |   |    RCV   |               |
        +---------+   +----------+               |
            |             |                      |
        Server FIN      Client FIN            TCP_TRANS
            |             |                    T.O.
            V             V                      |
        +----------------------+                 |
        |   C FIN + S FIN RCV  |-----------------+
        +----------------------+ 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Juliusz Chroboczek
> Envoyé : vendredi 28 avril 2017 21:47
> À : Joe Touch
> Cc : [email-masked]
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> 
> >>> [Med] The main point Joe is that the IETF has standard track documents
> >>> that specify a TCP state machine when NAT is used. We are leveraging
> >>> that state machine for the MPTCP proxy work.
> 
> >> I think that's an important point.
> 
> > And I think it is incorrect, at least for the split-TCP case.
> 
> Yes, I think that what Mohammed is saying is that the "plain mode proxy",
> as currently defined, requires NAT-style techniques.  I'd argue that this
> makes it neither plain nor a proxy.
> 
> -- Juliusz
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 May 2017 10:02:43 -0700

Med,

Standard TCP state diagrams don't have many of the states you note
below. The diagrams are Mealy machines, indicating the triggering event
(timer expiration, user API action, or incoming segment) paired with a
corresponding action (timer set, user API response, and/or outgoing
segment). Also, standard TCP state diagrams all refer to a single
socketpair association.

It would be useful to revise your diagram accordingly and include it and
supporting references in the next update.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 8 May 2017 15:09:04 -0700

I think this is a valid point for discussion and it's good to see people
are generally fine to explore proxy for mptcp in general with a certain
conditions.

It seems to me that the option #2 in slide 12 of the chair slide (SOCKS
type approach) can fulfill this criteria. Because it looks like a
conventional proxy approach to me. The downside would be 0-RTT won't be
possible with this. It will be at least 1-RTT.

BTW, I guess there is one mistake in the slide. I think in option #2, the
SYN will be sent to Home Gateway with Proxy, not to other TCP endpoint.
--
Yoshi

On Fri, Apr 28, 2017 at 8:53 AM, Joe Touch <[email-masked]> wrote:

> Med,
>
> There are two possibilities, as I already stated:
>
>     a) this is a conventional proxy, which is fine with me
>
>     b) this is a split-TCP proxy, which is out of scope IMO for this
> group and I do not support
>
> It's not feasible to endorse this work while letting this issue "float".
>
> The current doc is fairly clear on being (b).
>
> I have made my position clear and given the appropriate ADs a heads-up.
>
> Joe
>

---

From: <[email-masked]>
Date: Fri, 12 May 2017 07:55:22 +0000

Hi Joe, 

Sure. That's something we can consider.  

We are waiting for the chairs' summary for this consensus call. 

Cheers,
Med

> De : Joe Touch [mailto:[email-masked]]
> Envoyé : mardi 2 mai 2017 19:03
> À : BOUCADAIR Mohamed IMT/OLN; Juliusz Chroboczek
> > We are leveraging on existing IETF endorsed behaviors (defined in BCPs).
> In particular, we are assuming this simplified state machine by the proxy:
> >