Re: [multipathtcp] Proposed changes to the protocol draft

[Olivier Bonaventure <[e-mail]>]

Hello,
> 
> 2011/9/9 Hampel, K Georg (K Georg) <[e-mail]>om>:
>> Hi Christoph, Costin, Yoshifumi, all,
>>
>> Fallback issue: I agree that when checksums are not used, there is no way for the end hosts to tell if payload has been rewritten, and hence, there's no reason to enter fallback due to payload rewriting. Obviously, if payload rewriting still occurs, the connection may get corrupted or it may break.
>>
>> I'm striving for something else: If checksums are *not* used and only one subflow runs traffic, DSS can principally be omitted. 

We'd need to define precisely define when there is a single subflow that
runs traffic.

Does this means that only one flow has been established ? or only one
subflow is active (e.g. previous subflows have timedout) or there
unacknowledged data on only one subflow ? or another definition ?

We need an unambiguous definition that can be easily supported by
implementations

> This reduces overhead and improves processing speed. 

But this increases the implementation complexity and the number of
corner cases that have to be considered by implementors.

>Omission of DSS can be announced via DSS with infinity setting. DSS must be re-inserted as soon as another subflow carries traffic. This is done via conventional DSSs.

Implementations will also need to hanlde the case when :
- at time t0, there is a single subflow and thus dss=infinite
- at time t1, a second subflow is used and thus we send dss
- at time t2, we go back to a single subflow and dss=infinite

I fear that this would add unnecessary complexity and would prefer to
wait for more implementation experience before looking at such
optimisations in the main spec


>> What problems does this simplification raise?
> 
> Please correct me if I'm wrong.
> In my understanding, there seems to be two distinct modes in this.
> 
>    fallback mode:  where we want to omit MPTCP signaling since it
> might not be very safe.

Agree. As soon as we go in fallback mode, we must stop all MPTCP signalling.

>    one path mode: where we want to suppress MPTCP signaling to reduce
> the overhead and improve the performance.
> 
> I'm so far inclined to disable all MPTCP features (including opening
> subflows) in the fallback mode.

Agreed


>> Proxy issue:
>> First a clarification (in my opinion): In presence of a proxy, there can *only* *ever* be two independent "end points" that do MPTCP signaling. If host A and host B do MPTCP, the proxy must remain out of the picture and let all MPTCP signaling pass. If the proxy wants to be in the picture, it has to shun host A's MPTCP signaling from host B and respond on behalf of host A.
> 
> Well, I'm not sure if this is a good example, But, a mobile MPTCP node
> in future might want to say something like this...
> "I'm going to leave this network and will come back with new address
> after for a while. In the meantime, you can send data to this proxy if
> you want"

Adding proxy to the main spec will add complexity to the protocol.
Wouldn't it be better to :
- reserve a few bits in the main spec to have some space to add the
proxy bits that are being discussed but leave proxy out of the main spec
- start a new draft that works on these proxy issues

MPTCP has already several use cases without proxies and I think that it
is important to stabilise the main MPTCP spec based on implementation
experience before trying to add new features and new complexity.



Olivier


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be