Subject: Re: [multipathtcp] potential MPTCP proxy charter item
From: <[email-masked]>
To: Joe Touch <[email-masked]>, Mirja Kühlewind<[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 8 Nov 2016 10:07:07 +0000
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>

Joe,

I'm inserting the full text of that section here: 

====
         4.2.2.5  TCP Options: RFC-793 Section 3.1

            A TCP MUST be able to receive a TCP option in any segment.
            A TCP MUST ignore without error any TCP option it does not
            implement, assuming that the option has a length field (all
            TCP options defined in the future will have length fields).
            TCP MUST be prepared to handle an illegal option length
            (e.g., zero) without crashing; a suggested procedure is to
            reset the connection and log the reason.
====

   The proposed design for the MP_CONVERT option does not violate that
   text, IMO.  I'm listing here the design approaches that we considered
   so far:

      (1) no change to MP_CAPABLE: MPTCP proxies are prepared by design
      to look at the payload of SYN to retrieve MP_CONVERT options.

      *  MP_CONVERT options are inserted in the payload of a SYN that
         includes MP_CAPABLE.
      *  If the remote peer does not support MPTCP, the connection will
         be reverted to TCP according to the base MPTCP specification.
      *  If the remote peer supports MPTCP, and it is prepared to
         receive options in the SYN payload, it will echo those options
         in the SYN/ACK.  The MPTCP connection will continue.
      *  If the remote peer supports MPTCP, but it is not prepared to
         receive options in the SYN payload, it will reply with a SYN/
         ACK that does not echo MP_CONVERT.  
      *  The capabilities of the MPTCP proxy may be stored locally to
         determine whether future connections can make use of the
         MP_CPNVERT or not.  Of course, this information will be flushed
         if a new MPTCP proxy is configured, or after the expiry of a
         timer.  This is particularly useful for the explicit mode where
         it is likely that the same MPTCP proxy will handle all
         connections from the same subscriber.

     (2) change MP_CAPABLE to explicitly indicate that options are
      present in the SYN payload:

      *  A flag in the MP_CAPABLE will be set to indicate to a remote
         peer that MP_CONVERT options are included in the payload.
      *  If the remote peer does not support MPTCP, the connection will
         be reverted to TCP as per base MPTCP specification.
      *  If the remote peer supports MPTCP, and is prepared to receive
         options in the payload, it will echo the flag in the SYN/ACK
         (and eventually the options).  The MPTCP connection will
         continue.
      *  If the remote peer supports MPTCP, but does not support that
         Flag, it won't echo the flag in the SYN/ACK.
      *  The capabilities of the MPTCP proxy may be stored locally to
         determine whether future connections can make use of the
         MP_CPNVERT or not.  Of course, this information will be flushed
         if a new MPTCP proxy is configured, or after the expiry of a
         timer.  This is particularly useful for the explicit mode where
         it is likely that the same MPTCP proxy will handle all
         connections from the same subscriber.

   CONCLUSION: The proposed design satisfy both requirements in
   Section 4.2.2.5.  In particular, this one: "A TCP MUST ignore without
   error any TCP option it does not implement"

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de Joe
> Touch
> Envoyé : lundi 7 novembre 2016 17:34
> À : Mirja Kühlewind; [email-masked]
> Cc : [email-masked]
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> More specifically - see section 4.2.2.5 of rfc1122.
> 
> Joe
> 
> > On Nov 7, 2016, at 8:07 AM, Joe Touch <[email-masked]> wrote:
> >
> > Oh - a quick followup.
> >
> > If you have an option that "poisons" the connection if not confirmed (as
> > would using long EDO inside the SYN), then you have to retry without
> > that option. That is *possible*, but there's another problem.
> >
> > RFC793 defines options as optional. Making any option mandatory would
> > require updating RFC793. That sort of change is exactly why long EDO
> > (actually extending the option space, rather than declaring the
> > capability) is currently prohibited in EDO.
> >
> > Joe
> >
> >
> >> On 11/7/2016 7:56 AM, Joe Touch wrote:
> >>
> >>> On 11/7/2016 7:42 AM, Mirja Kühlewind wrote:
> >>> Do you mean the MCP forwards the original SYN (and basically does
> nothing if the server supports MPTCP) or does the MCP terminate the TCP
> connection and start a new TCP connection with MP_CAPABLE towards the
> server?
> >>>
> >>> Mirja
> >> If you're OK with needing to terminate a failed option exchange, then
> it
> >> might be possible to use EDO in the SYN in its current form.
> >>
> >> TCPM decided to prohibit that in the general case, but I could ask them
> >> to allow that in very limited environments (but it could NEVER be
> >> default on).
> >>
> >> Note - the use cases I'm hearing appear to assume very strong knowledge
> >> about the other end of the connection and the path. In that case, you
> >> probably can skip most - if not all - of the 'negotiation' options and
> >> just start using them during the SYN too. However, if you say "no, we
> >> need to confirm", then you would not be able to use EDO inside the SYN.
> >>
> >> Joe
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp