Archive

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

On 5/2/2017 1:40 AM, mohamed.boucadair@orange.com wrote:
> 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:multipathtcp-bounces@ietf.org] De la part de
>> Juliusz Chroboczek
>> Envoyé : vendredi 28 avril 2017 21:47
>> À : Joe Touch
>> Cc : multipathtcp@ietf.org
>> 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
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp