Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch > Envoyé : mercredi 19 juillet 2017 21:58 > À : Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP > > > > On 7/19/2017 12:51 PM, Olivier Bonaventure wrote: > > Joe, > >>>> > >>>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > >>>>>> - IMO, TCP always needs to be able to fall back (which should be > >>>>>> true now) > >>>>> > >>>>> This is not a concern with the proposed design > >>>> Prove that is true if/when TCP-AO is enabled. > >>> > >>> I don't think that TCP-AO is a use case for the proposed converters. > >> > >> You don't get to decide that. If you use TCP, then TCP-AO could be > >> enabled on the client. > > > > The converter is not intended to be used for all TCP connections. In > > the draft we explain how an MPTCP endpoint can bypass the converter if > > the destination server supports MPTCP. For TCP-AO, my recommendation > > would be that the default policy of the client would be to never use > > the converter if TCP-AO is requested by the application. > > How do you know you're using the converter? [Med] The converter is explicilty configured (e.g., locally configured or y means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07). Is the initial connection to > that converter? [Med] When a connection is eligible to network-assisted MPTCP, the first subflow will be established via the converter. Subsequent flows will be established with that proxy involved. Packets are sent with destination IP address set to the one of the converter. Or does the converter hijack (the latter is the > implication of the text, AFAICT). > > Joe > > _______________________________________________ > Int-area mailing list > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
