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é : vendredi 10 juillet 2015 16:30
> À : 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,
> 
> >
> > A change was proposed in
> > (https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02) to
> > redefine IPVer field of ADD_ADDR as a set of flag bits (see below). This
> > change applies also for ADD_ADDR2.
> 
> 
> I think that replacing the IP version with a set of flags (at least in
> ADD_ADDR2 to prevent backward compatibility problems with the existing
> ADD_ADDR implementation) would make sense.

[Med] Ok.

> 
> >                                          +-+-+-+-+
> >
> >        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? 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.  

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

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


> 
> 
> Olivier