Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Rao Shoaib [mailto:[e-mail]]
> Envoyé : vendredi 3 juin 2016 09:53
> À : BOUCADAIR Mohamed IMT/OLN; [e-mail];
> [e-mail]
> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> 
> 
> 
> On 06/03/2016 12:41 AM, [e-mail] wrote:
> > Hi Shoaib,
> >
> > I'm sure you have good reasons why TCP is not used between the client
> and the server in the first place. Calling out those reasons is helpful.
> MPTCP allows us to break a large UDP message into several segments and
> use multiple paths, Plus the added reliability. 

[Med] Ok, thanks.

This reminds me of
> another issue, what happens if a fragment other than the 1st one that
> carries the header shows up first ?

[Med] This is an issue for IPv4. In order to accommodate our of order fragments, the implementation caches those till the first fragment that contains the transport information is received. We hinted this in the draft:

   In order to protect the CPE and the concentrator and minimize the
   risk of degrading the overall bonding service performance, dedicated
   resources SHOULD be reserved for handling fragments (e.g., by               
   limiting the amount of resources to process out-of-order packets).
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 We need a header in each packet that
> indicates the order and association just like IP fragmentation.

[Med] There are two cases for handling IPv4 fragments: 

(1) IPv4 fragments that are received from the Internet or IPv4 received from the LAN: for those, I proposed the following behavior (not yet discussed with my co-authors): 

5.3.1.  Receiving IPv4 Fragments on the Internet-Facing Interface of the
        Concentrator

   The forwarding of an IPv4 packet received on the Internet-facing
   interface of the concentrator requires the IPv4 destination address
   and the transport-protocol destination port for binding lookup
   purposes.  If the first packet received contains the transport-
   protocol information, the concentrator uses a cache and forwards the
   fragments unchanged (i.e., without reassembly).  A description of
   such a caching algorithm is outside the scope of this document.  If
   subsequent fragments arrive before the first fragment, the
   concentrator SHOULD queue these fragments till the first fragment is
   received.

   The processing of the first fragment MUST follow the same procedure
   as in Section 5.1.1.  The rewriting of the IP addresses of subsequent
   fragments MUST follow the instructions maintained in the binding
   table and the fragmentation cache.  The MF (More Fragments) bit and
   'Fragment offset' field MUST NOT be modified by the concentrator.

5.3.2.  Receiving IPv4 Fragments from the LAN

   If the first packet received contains the transport-protocol
   information, the CPE uses a cache and forwards the fragments
   unchanged (i.e., without reassembly).  If subsequent fragments arrive
   before the first fragment, the concentrator SHOULD queue these
   fragments till the first fragment is received.

   The processing of the first fragment MUST follow the same procedure
   as in Section 5.1.2.  The rewriting of the IP addresses of subsequent
   fragments MUST follow the instructions maintained in the binding
   table and the fragmentation cache.  The MF bit and 'Fragment offset'
   field MUST NOT be modified by the CPE.

(2) Large packets that need to be fragmented when relayed into the MPTCP connection: The proposal is to fragment those only after the UDP/TCP conversion is achieved, and reassembly at the remote side before TCP/UDP conversion. Please refer to Section 5.3.


> >
> > As a side note, the plain mode specification does not enforce (yet) a
> validation check to assess whether the address conveyed in the option is
> distinct from an address that belong to the MPTCP node that receives the
> option. I.e., if that node receives an option that includes ones of its IP
> addresses, it is an indication that the data is to be consumed locally,
> not forwarded outside. Wouldn't that solve the first part of your "address
> mapping" concern?
> Correct but why would I even want to send an IP address ?

[Med] Fair point. I was referring to -07. (An optimization would be indeed that the client does not include an IP address if the ultimate DST address is equal to the destination IP address of the MPTCP peer).   

 Why can't
> there be a flag to indicate that this packet carries no address
> translation information. 

[Med] You don't need a flag for this. You can rely on the length of the option as an explicit indication that no address is included. 

Ideally encapsulation should be an option on
> it's own as it has nothing to do with address translation.
> 
> Shoaib
> >
> > BTW, I added a note to the draft to indicate the following:
> >
> > * An implementation must ignore PM options that include multicast,
> broadcast, and host loopback addresses.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Rao Shoaib [mailto:[e-mail]]
> >> Envoyé : mercredi 1 juin 2016 18:16
> >> À : BOUCADAIR Mohamed IMT/OLN; [e-mail];
> >> [e-mail]
> >> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> >>
> >>
> >>
> >> On 05/30/2016 02:22 AM, [e-mail] wrote:
> >>> Hi Shoaib,
> >>>
> >>> Please see inline.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : multipathtcp [mailto:[e-mail]] De la part
> de
> >> Rao
> >>>> Shoaib
> >>>> Envoyé : samedi 28 mai 2016 10:56
> >>>> À : [e-mail]; [e-mail]
> >>>> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> >>>>
> >>>>
> >>>>
> >>>> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote:
> >>>>> Rao,
> >>>>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote:
> >>>>>>> The assumption is that this solution will be deployed in
> controlled
> >>>>>>> environments and only used between the CPE and the Concentrator.
> >> Since
> >>>>>>> the operator controls the two networks that are bound together, he
> >> can
> >>>>>>> verify that there are no middleboxes that drop the PM option.
> >>>>>>>
> >>>>>>>
> >>>>>>> Olivier
> >>>>>> I am extremely interested in encapsulating UDP in MPTCP but this
> >>>>>> solution is very specific and hence why should it even be
> >> standardized
> >>>> ?
> >>>>> There is a clear demand from operators for a solution to this
> problem
> >>>>> in hybrid access networks.
> >>>> OK but this solution is very specific to the mobile network.
> >>> [Med] The solution is not specific to the mobile network, but targets
> >> all network providers who want to allow their customers to make use of
> all
> >> available network attachments (e.g., fixed, WLAN, cellular, etc.)
> >> The way it is designed it is very specific to a particular use case and
> >> is not a generic encapsulation solution.
> >>>    We would
> >>>> prefer a generic encapsulation solution which has no address mapping.
> >>> [Med] It seems that you want to cover the case of an MPTCP-enabled
> host
> >> communicating an MPTCP-enabled server exchanging any protocol data
> inside
> >> an MPTCP connection? Can you please confirm/infirm?
> >> Yes. We want a generic MPTCP encapsulation solution with no address
> >> mapping. Address mapping and other features (like single connection)
> >> should be separate options.
> >>>> Maybe the address mapping part should be made optional based on a
> flag
> >> ?
> >>> [Med] The technical details can be worked out once we understand your
> >> deployment case.
> >>> [snip]
> >> OK.
> >>>
> >>> After re-reading the draft I think the proposal for encapsulation is
> >>> pretty good, only minor details need to be cleared up.
> >>>
> >>> [Med] Thank you. We are more than open to discuss those details.
> >>>
> >>>
> >> Great. I think first we need to decide if we want a generic
> >> encapsulation solution (which is why I want) or do we entangle it with
> >> the other requirements of the cellular deployment.
> >>
> >> Shoaib