Re-, I don't understand your argument here, especially because you are the one who proposed me the following (check mptcp archives, April 20, 2017) which we endorsed in the latest version of the specification:
"If that were the case, you'd simply be defining a new application service and asking for a TCP port number." Are you saying that you suggested us a bad design choice? Thank you. Cheers, Med > -----Message d'origine----- > De : Int-area [mailto:[email protected]] De la part de Joe Touch > Envoyé : mercredi 19 juillet 2017 18:43 > À : Olivier Bonaventure; Internet Area; [email protected] > Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP > > > > On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > > Joe, > > > >> - but I remain concerned with "injection piggybacking" > > > > To which section of the draft are you referring to ? > It starts in the arch discussion in Sec 2: > > As shown in Figure 3, the Converter places its supplied information > inside the handshake packets. > > That's what I refer to as "injection piggybacking" > > With TCP, the Converter protocol places the destination address and > port number of the final Server in the payload of the SYN. > > And that is the part that violates RFC793 semantics when that SYN reaches > the final destination rather than the server-side proxy. > > To be clear, I'm not interested in further trying to "fix" this mechanism > so it can work. It can't and it shouldn't IMO. Let's use our cycles for > more productive things. > > Joe > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
