Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

[Olivier Bonaventure <[e-mail]>]

Yoshifumi,

>
>     There is already operational experience with this type of
>     MPTCP-based solutions and if you think that this would be useful, we
>     could organise a presentation at the next IETF meeting on this
>     experience
>
>
> I think I understand general idea.
> But, as far as I read the draft, I got an impression that a UDP or a TCP
> flow will be mapped to a single subflow of a mptcp session.

No, since the PM option is carried in the SYN of the initial subflow, a 
TCP flow will be mapped onto an MPTCP connection (and thus will be able 
to use any of its subflows)

> There is no description about using multiple subflows for a single
> TCP/UDP flow, or updating subflow mappings in the middle of a session.
> I think the draft should mention these cases.

Since the mapping is between a TCP connection (UDP flow) and an MPTCP 
connection, it applies for all the subflows of the MPTCP connection 
automatically. I'm not in favor of changing the mapping during the 
lifetime of an MPTCP connection, it leads to implementation complexity 
that are not worth the effort given that we can establish another MPTCP 
connection bound to another flow.

>
>         2: Including data in SYN is allowed in RFC793, but I'm not very
>         sure how
>         many implementations actually accept it.
>
>
>     Well, the deployment of TFO shows that this is possible.
>
>         I think the draft should
>         discuss this point. Also, what will happen if PM option is
>         included in
>         the payload, but it is removed by the middleboxes?
>
>
>     The assumption is that this solution will be deployed in controlled
>     environments and only used between the CPE and the Concentrator.
>     Since the operator controls the two networks that are bound
>     together, he can verify that there are no middleboxes that drop the
>     PM option.
>
>
> Hmm. then, I think these presumptions should be listed in the draft.
> But, one concern is the proposal will be too specific to standardize if
> there're too much presumptions...

We can add a section on middlebox interference and discuss how the 
proposal would work when there is a middlebox even if the most likely 
deployment is an environment without middleboxes that interfere with 
TCP. Having NAT on any of the paths does not create any problem. The 
problematic middleboxes are, as always with MPTCP, those that :
- remove some TCP options
- remove data from the SYN payload



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.