Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis

[Olivier Bonaventure <[e-mail]>]

Med,

>>
>>>                                           +-+-+-+-+
>>>
>>>         Flags is a set of 4 flags:        |C|r|r|r|
>>>
>>>                                           +-+-+-+-+
>>>
>>>         C flag MUST be set to 1 when the address/port are checked.
>>>
>>>         "rrr" are for future assignment as additional flag bits.
>>>
>>>         r bits MUST each be sent as zero and MUST be ignored on receipt.
>>>
>>
>> However, I'm stil not convinced by the usefulness of using the C bit
>> that you propose. If a host knows that it cannot receive a SYN over a
>> given address, then the best solution is to not advertise this address.
>
> [Med] Agree. An implementation that supports the "C" flag is likely to advertise addresses/ports for which pinholes have been created in NATs/FWs and address/ports that can be used to receive incoming packets successfully.


> The issue with the implicit approach (i.e., no C-flag) is at the server side: should the server interpret the advertisement of an address/port as an indication that packets can be sent without experiencing reachability issues or not?

This is what RFC6824 assumes today. ADD_ADDR is only a hint about the 
possibility of trying to reach this address. Anyway it will be a SYN and 
the host will wait for a SYN+ACK to confirm the reachability

> The experience has shown that only the endpoint who initiated the first subflow can create new ones even if addresses/ports have been announced to the remote peer.

AFAIK, there has been no experience on letting the server create 
subflows on the Internet and see what happens. The existing 
implementation have assumed that this would be difficult and they have 
not implemented the code to allow the server to create subflows, but 
this could be done. It will likelly work in private networks or datacenters

>
> The explicit approach (c-flag) explores an alternate approach that is worth to be investigated, IMHO.

We should probably first try to create subflows from the server. We 
might be able to install a test server to analyse this on
multipath-tcp.org after the holidays. This could give use data on the
possibility of creating subflows from the server and the problems that 
such a feature could cause.
>
>> This will typically be the case when a host is behind a NAT or a
>> firewall (I guess that at some point middlebox vendors will include
>> software to parse ADD_ADDR and remove the ADD_ADDR that correspond to
>> addresses that are not reachable accoring to their policies)
>
> [Med] We can also consider some middleboxes (read CPEs) that will set the C-flag on behalf of an endpoints for a better quality of experience.

I'm not sure that expecting middleboxes to change the content of the 
ADD_ADDR is a good approach in the long term. We've seen various 
problems with middleboxes that change the content of packets


Olivier