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

[Christoph Paasch <[e-mail]>]

Hello,

On 15/07/15 - 16:48:40, Olivier Bonaventure wrote:
> >>>                                          +-+-+-+-+
> >>>
> >>>        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

I think, concerning the reachability, what is rather interesting is to
advertise the secondary address without wanting the peer to even try
establishing a new subflow to this address. This advertisement is done in
case the "primary" subflow becomes unreachable. If it becomes unreachable,
then the peer can use the advertised address to create a new subflow.

It's a little bit like the "handover"-mode we did some time ago in the Cellnet,
but the other way around (peer creates the subflows not the client).


Cheers,
Christoph

> >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
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp