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

[<[e-mail]>]

Hi Olivier, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Olivier Bonaventure [mailto:[e-mail]]
> Envoyé : mercredi 15 juillet 2015 16:49
> À : BOUCADAIR Mohamed IMT/OLN; [e-mail];
> [e-mail]
> Objet : Re: [multipathtcp] Preparing for Prague meeting - things to delete
> or add to MPTCP protocol bis
> 
> 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

[Med] when multiple alternate addresses are available, having the c-flag will help the remote side decide which address to pick rather than try-and-see approach that may not be optimal. c-flag can be considered an additional hint.

> 
> > 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
>