Subject: [multipathtcp] Stateless subflow aggregation and steering

From: Mahesh M <[email-masked]>
Date: Mon, 18 Jun 2012 19:11:29 -0700

Hi,

I have two question with regards to subflows.

1.       When a SYN is received with MP_JOIN option, receiver cannot reply without allocating any state on its send, at least it has to remember the senders random number from the MP_JOIN option. Theoretically one cannot do full stateless syncookie.

2.       With requirement to aggregate multiple subflows with different 4 tuples, in multi core architecture, it should be possible to steer all the related flows to same processing core. If mapping between connections and token are maintained in a shared memory, packet steering can be done after looking up the mapping with some overhead.  But there can be implementation where there is no shared memory and here packet steering is done using stateless mechanism like hash based on the 4tuple(assume application run on same core where packets are steered). Extending DSS option to insert 2byte state information and same is echoed back by the peer always just like data ack. When DSS option is used with its full length along with SACK or TIMESTAMP, we will still get 2bytes  in front of SACK/TIMESTAMP option to extend the DSS option.

Regards,
Mahesh

---

From: Alan Ford <[email-masked]>
Date: Tue, 19 Jun 2012 08:52:07 +0100

Hi Mahesh,

1. Yes, there is no support for stateless operation on MP_JOIN. This is
deliberate, in order to simplify the protocol overhead. The primary purpose
of stateless operation is to prevent resources being allocated
unnecessarily, e.g. in the case of a DoS attack. The MP_JOIN already has a
form of protection: the token provided has to match one that the server
already knows, otherwise the MP_JOIN will be ignored.

2. This sounds like an corner case and one that does not warrant using 2
bytes of the protocol for. The most obvious solution would be to do mappings
based on the port number (all subflows should use the same local port, if
possible  and you could always reject them if they do not).

Regards,
Alan

On 19/06/2012 03:11, "Mahesh M" <[email-masked]> wrote:

> 1.       When a SYN is received with MP_JOIN option, receiver cannot reply
> without allocating any state on its send, at least it has to remember the
> senders random number from the MP_JOIN option. Theoretically one cannot do
> full stateless syncookie.
> 
> 2.       With requirement to aggregate multiple subflows with different 4
> tuples, in multi core architecture, it should be possible to steer all the
> related flows to same processing core. If mapping between connections and
> token are maintained in a shared memory, packet steering can be done after
> looking up the mapping with some overhead.  But there can be implementation
> where there is no shared memory and here packet steering is done using
> stateless mechanism like hash based on the 4tuple(assume application run on
> same core where packets are steered). Extending DSS option to insert 2byte
> state information and same is echoed back by the peer always just like data
> ack. When DSS option is used with its full length along with SACK or
> TIMESTAMP, we will still get 2bytes  in front of SACK/TIMESTAMP option to
> extend the DSS option.
> 
>  
> Regards,
> Mahesh 
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Mahesh M <[email-masked]>
Date: Tue, 19 Jun 2012 00:57:57 -0700

2. This sounds like an corner case and one that does not warrant using 2 bytes of the protocol for. The most obvious solution would be to do mappings based on the port number (all subflows should use the same local port, if possible - and you could always reject them if they do not).
Mahesh>  It is not a corner case, for example any packet processing engine implemented in user space usually will not share the session with other engines, they rely on L2 layer distributing packets based on the 4tuple. Restricting the source port is not a practical solution since receiver does not have control on the source port for client. Also distribution based on the source port may not give good distribution across the packet processing engines.

Regards,
mahesh

From: Alan Ford [mailto:[email-masked]]
Sent: Tuesday, June 19, 2012 12:52 AM
To: Mahesh M; [email-masked]
Subject: Re: [multipathtcp] Stateless subflow aggregation and steering

Hi Mahesh,

1. Yes, there is no support for stateless operation on MP_JOIN. This is deliberate, in order to simplify the protocol overhead. The primary purpose of stateless operation is to prevent resources being allocated unnecessarily, e.g. in the case of a DoS attack. The MP_JOIN already has a form of protection: the token provided has to match one that the server already knows, otherwise the MP_JOIN will be ignored.

2. This sounds like an corner case and one that does not warrant using 2 bytes of the protocol for. The most obvious solution would be to do mappings based on the port number (all subflows should use the same local port, if possible - and you could always reject them if they do not).

Regards,
Alan

Regards,
Mahesh
________________________________
_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Alan Ford <[email-masked]>
Date: Tue, 19 Jun 2012 09:02:32 +0100

I meant the destination port.

By default MPTCP will send to the same port number on the alternative IP
addresses. You can also choose the ports from which you open. You could
reject any additional subflows trying to be set up to other ports.

Maybe you could also distribute based on token?

Regards,
Alan

On 19/06/2012 08:57, "Mahesh M" <[email-masked]> wrote:

> 2. This sounds like an corner case and one that does not warrant using 2 bytes
> of the protocol for. The most obvious solution would be to do mappings based
> on the port number (all subflows should use the same local port, if possible 
> and you could always reject them if they do not).
> Mahesh>  It is not a corner case, for example any packet processing engine
> implemented in user space usually will not share the session with other
> engines, they rely on L2 layer distributing packets based on the 4tuple.
> Restricting the source port is not a practical solution since receiver does
> not have control on the source port for client. Also distribution based on the
> source port may not give good distribution across the packet processing
> engines.
>  
> Regards,
> mahesh
>  
> 
> deliberate, in order to simplify the protocol overhead. The primary purpose of
> stateless operation is to prevent resources being allocated unnecessarily,
> e.g. in the case of a DoS attack. The MP_JOIN already has a form of
> protection: the token provided has to match one that the server already knows,
> otherwise the MP_JOIN will be ignored.
> 
> 2. This sounds like an corner case and one that does not warrant using 2 bytes
> of the protocol for. The most obvious solution would be to do mappings based
> on the port number (all subflows should use the same local port, if possible 
> and you could always reject them if they do not).
> 
> Regards,
> Alan
> 
>

---

From: Mahesh M <[email-masked]>
Date: Tue, 19 Jun 2012 01:06:39 -0700

Hi,

Distribution based on one port may not scale well.
Since only SYN packet carries token, we cannot steer the non SYN packets based on token.

Regards,
Mahesh

From: Alan Ford [mailto:[email-masked]]
Sent: Tuesday, June 19, 2012 1:03 AM
To: Mahesh M; [email-masked]
Subject: Re: [multipathtcp] Stateless subflow aggregation and steering

By default MPTCP will send to the same port number on the alternative IP addresses. You can also choose the ports from which you open. You could reject any additional subflows trying to be set up to other ports.

Regards,
Alan

Regards,
mahesh

Hi Mahesh,

Regards,
Alan

Regards,
Mahesh

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 19 Jun 2012 10:16:46 +0200

Hello,

On Tuesday 19 June 2012 00:57:57 Mahesh M wrote:
>> bytes of the protocol for. The most obvious solution would be to do
>> mappings based on the port number (all subflows should use the same local
>> port, if possible - and you could always reject them if they do not).
> not have control on the source port for client. Also distribution based on
> the source port may not give good distribution across the packet processing
> engines.

in our Linux Kernel implementation we handle flow-to-core affinity by using 
the Receive-Flow-Steering framework. That way, all subflows are sent to the 
same CPU-core (irregardless of the port-numbers).

Have a look at the IETF-83 presentation:
http://tools.ietf.org/agenda/83/slides/slides-83-mptcp-3.pdf

And some info about RFS:
http://code.google.com/p/kernel/wiki/NetScalingGuide

Cheers,
Christoph

-- 
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--

---

From: Mahesh M <[email-masked]>
Date: Tue, 19 Jun 2012 01:23:51 -0700

Hi,

If understood this implementation correctly, implementation is kernel and all the cores have access to the all the token/core and 4tuple/core mapping. So it will be just like using shared memory for storing the mapping. If packet engines run on different boxes or TCP stack is in user space, shared memory logic may not work.

Regards,
Mahesh
 
-----Original Message-----
From: Christoph Paasch [mailto:[email-masked]] On Behalf Of Christoph Paasch
Sent: Tuesday, June 19, 2012 1:12 AM
To: [email-masked]
Cc: Mahesh M
Subject: Re: [multipathtcp] Stateless subflow aggregation and steering

Hello,

On Tuesday 19 June 2012 00:57:57 Mahesh M wrote:
>> 2. This sounds like an corner case and one that does not warrant 
>> using 2 bytes of the protocol for. The most obvious solution would be 
>> to do mappings based on the port number (all subflows should use the 
>> same local port, if possible - and you could always reject them if they do not).
> Mahesh>  It is not a corner case, for example any packet processing 
> Mahesh> engine
> implemented in user space usually will not share the session with 
> other engines, they rely on L2 layer distributing packets based on the 4tuple.
> Restricting the source port is not a practical solution since receiver 
> does not have control on the source port for client. Also distribution 
> based on the source port may not give good distribution across the 
> packet processing engines.

in our Linux Kernel implementation we handle flow-to-core affinity by using the Receive-Flow-Steering framework. That way, all subflows are sent to the same CPU-core (irregardless of the port-numbers).

And some info about RFS:

Cheers,
Christoph

--
IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain
--