Subject: [multipathtcp] draft agenda for Berlin meeting

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 17 Jul 2013 16:28:10 -0700

Hello,
.
We've uploaded draft agenda for Berlin meeting on the following URL.

http://tools.ietf.org/wg/mptcp/agenda

--
Yoshifumi & Phil

---

From: Krishna Khanal <[email-masked]>
Date: Wed, 24 Jul 2013 08:05:40 +0000

Hi,
	For stateless implementation of MP_CAPABLE flow, there is no way to continue with MPTCP if the final ack of 3-way MP_CAP handshake is dropped or the data packet is received before the MP_CAP ack due to out of ordering of the packet in the network. Only way to continue with the transaction is to fallback to regular TCP and there is a pretty much chance of happening this in the real network. So, there is always a requirement of fallback even if the middle devices supports and understands MPTCP.

Is there any thought on making MP_CAP final ack reliable like MP_JOIN final ack or including MP_CAP final ack options with the data packet along with DSS packet until the ack is received? Second, option may not be suitable because it consumes all the option space and first option also tend to increase the handshake duration and block the request by atleast an RTT.

Any thought?

Regards,
Krishna

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 24 Jul 2013 11:08:55 +0200

Hello Krishna,

On 24/07/13 - 08:05:40, Krishna Khanal wrote:
> Hi, For stateless implementation of MP_CAPABLE flow, there is no way to
> continue with MPTCP if the final ack of 3-way MP_CAP handshake is dropped
> or the data packet is received before the MP_CAP ack due to out of
> ordering of the packet in the network. Only way to continue with the
> transaction is to fallback to regular TCP and there is a pretty much
> chance of happening this in the real network. So, there is always a
> requirement of fallback even if the middle devices supports and
> understands MPTCP.
> 
> Is there any thought on making MP_CAP final ack reliable like MP_JOIN
> final ack or including MP_CAP final ack options with the data packet along
> with DSS packet until the ack is received? Second, option may not be
> suitable because it consumes all the option space and first option also
> tend to increase the handshake duration and block the request by atleast
> an RTT.
> 
> Any thought?

In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in a
reliable way, as it is done today for the third ACK with the MP_JOIN. But
this got removed due to the additional RTT:

http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html

Then, the status of the draft was for some time that MPTCP was doing
reliable transmission of the third ACK+MP_CAPABLE, but allowed sending data
before the arrival of this third ACK. However, this did not help, as early
arrival of data (prior to the third ACK) will still trigger a fallback. So,
the MPTCP-draft changed to a non-retransmitting third-ack as it is for today:

http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html

It would not be possible to combine MP_CAPABLE with the DSS-option and still
use stateless connection establishment:

MP_CAPABLE: 20 bytes
DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 bytes (Subflow-seq) + 4
bytes (Data-length + csum) = 16 bytes

So, there are 4 more bytes left. This would mean that we cannot put the
Timestamp-option, which is required for stateless connection establishment.

Cheers,
Christoph

---

From: Krishna Khanal <[email-masked]>
Date: Thu, 25 Jul 2013 04:51:13 +0000

Thanks Christoph for the information.

What about setting a flag in the SYNACK packet to tell the peer about the reliability of the final ack? If the administrator thinks it is ok to put a client on hold for an RTT, then they can set the flag in the synack packet and force client to do reliable transmission of final ack.

Regards,
Krishna

-----Original Message-----
From: Christoph Paasch [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 2:39 PM
To: Krishna Khanal
Cc: multipathtcp
Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior

Hello Krishna,

MP_CAPABLE: 20 bytes

Cheers,
Christoph

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 25 Jul 2013 09:46:24 +0200

Hello Krishna,

On 25/07/13 - 04:51:13, Krishna Khanal wrote:
> What about setting a flag in the SYNACK packet to tell the peer about the
> reliability of the final ack? If the administrator thinks it is ok to put
> a client on hold for an RTT, then they can set the flag in the synack
> packet and force client to do reliable transmission of final ack.

I'm not against this flag.
But, it should just be a signal of the server for the client, saying "I'm
doing stateless connection establishment". In the end, it's the client who
will decide if he wants to trade this additional RTT for assured
MPTCP-connectivity or not.

Cheers,
Christoph

> -----Original Message----- From: Christoph Paasch
> [mailto:[email-masked]] Sent: Wednesday, July 24, 2013 2:39
> PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP
> Final ack drop and fallback behavior
> 
> Hello Krishna,
> 
> > continue with MPTCP if the final ack of 3-way MP_CAP handshake is
> > dropped or the data packet is received before the MP_CAP ack due to out
> > of ordering of the packet in the network. Only way to continue with the
> > final ack or including MP_CAP final ack options with the data packet
> > along with DSS packet until the ack is received? Second, option may not
> > be suitable because it consumes all the option space and first option
> > also tend to increase the handshake duration and block the request by
> > atleast an RTT.
> > 
> > Any thought?
> 
> reliable transmission of the third ACK+MP_CAPABLE, but allowed sending
> data before the arrival of this third ACK. However, this did not help, as
> early arrival of data (prior to the third ACK) will still trigger a
> fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack as
> it is for today:
> 
> It would not be possible to combine MP_CAPABLE with the DSS-option and
> still use stateless connection establishment:
> 
> MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4
> bytes (Subflow-seq) + 4 bytes (Data-length + csum) = 16 bytes
> 
> Cheers, Christoph

---

From: Krishna Khanal <[email-masked]>
Date: Thu, 25 Jul 2013 08:26:24 +0000

Hi Christoph,
	Yes server sending its willingness but letting client decide on the reliability of final ack looks better. 

In my experience, there is significant fallback due to receiving data packet before final ack, though I don't have exact data to share here. Anyone having any experience with this?

Regards,
Krishna

-----Original Message-----
From: Christoph Paasch [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 1:18 PM
To: Krishna Khanal
Cc: multipathtcp
Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior

Hello Krishna,

Cheers,
Christoph

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 25 Jul 2013 10:29:57 +0200

Hello,

On 25/07/13 - 08:26:24, Krishna Khanal wrote:
> Hi Christoph, Yes server sending its willingness but letting client decide
> on the reliability of final ack looks better. 
> 
> In my experience, there is significant fallback due to receiving data
> packet before final ack, though I don't have exact data to share here.
> Anyone having any experience with this?

are you using the Linux implementation as a client?

I would be surprised if you have so many fallbacks, because you would need
a drop of the third ACK.
Thus you maybe have a high loss-rate on the path (?).

Cheers,
Christoph

> Regards, Krishna
> [mailto:[email-masked]] Sent: Thursday, July 25, 2013 1:18
> > What about setting a flag in the SYNACK packet to tell the peer about
> > the reliability of the final ack? If the administrator thinks it is ok
> > to put a client on hold for an RTT, then they can set the flag in the
> > synack packet and force client to do reliable transmission of final ack.
> 
> I'm not against this flag.  But, it should just be a signal of the server
> for the client, saying "I'm doing stateless connection establishment". In
> the end, it's the client who will decide if he wants to trade this
> additional RTT for assured MPTCP-connectivity or not.
> 
> 
> Cheers, Christoph
> 
> 
> > [mailto:[email-masked]] Sent: Wednesday, July 24, 2013
> > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp]
> > MP_CAP Final ack drop and fallback behavior
> > 
> > Hello Krishna,
> > 
> > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way
> > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake is
> > > dropped or the data packet is received before the MP_CAP ack due to
> > > out of ordering of the packet in the network. Only way to continue
> > > with the transaction is to fallback to regular TCP and there is a
> > > pretty much chance of happening this in the real network. So, there is
> > > always a requirement of fallback even if the middle devices supports
> > > and understands MPTCP.
> > > 
> > > along with DSS packet until the ack is received? Second, option may
> > > not be suitable because it consumes all the option space and first
> > > option also tend to increase the handshake duration and block the
> > > request by atleast an RTT.
> > > 
> > > Any thought?
> > 
> > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in
> > a reliable way, as it is done today for the third ACK with the MP_JOIN.
> > But this got removed due to the additional RTT:
> > 
> > data before the arrival of this third ACK. However, this did not help,
> > as early arrival of data (prior to the third ACK) will still trigger a
> > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack
> > as it is for today:
> >

---

From: Krishna Khanal <[email-masked]>
Date: Thu, 25 Jul 2013 08:35:39 +0000

Yes, I was using Linux Client.

Both drop and out of order are causing fallback. 

Regards,
Krishna

-----Original Message-----
From: Christoph Paasch [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 2:00 PM
To: Krishna Khanal
Cc: multipathtcp
Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior

Hello,

Cheers,
Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 29 Jul 2013 20:04:35 -0700

Hi,
Hmm.. I'm still thinking we need to solve this in the spec as reliable
solutions might require major changes..

I know this is tricky and not a very good idea, but it might improve a
situation a bit.
Let's say initiator's IW=4. if it wants to send something after
handshake, it may transmit data packets like this.

packet 1 with MPCAP
packet 2 with MPCAP
packet 3 with MPCAP
packet 4 with DSS (covers 1-4)

On the lost of these packets, it should retransmit them with DSS.
I know this doesn't keep the following rule in RFC6824 exactly, though.

   A sender MUST include a DSS option with data sequence mapping in
   every segment until one of the sent segments has been acknowledged
   with a DSS option containing a Data ACK.  Upon reception of the
   acknowledgment, the sender has the confirmation that the DSS option
   passes in both directions and may choose to send fewer DSS options
   than once per segment.

--
Yoshifumi

On Thu, Jul 25, 2013 at 1:35 AM, Krishna Khanal
<[email-masked]> wrote:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Krishna Khanal <[email-masked]>
Date: Tue, 30 Jul 2013 05:08:26 +0000

Hi,
	One problem with this approach is that the first packet needs to be split most of the time (or always ?), if the sender has a single packet request/data or it does not has knowledge of how much data is available to send in advance. Also, combining MPCAP with a single data packet should be sufficient, no need to combine with subsequent data packets.

Regards,
Krishna

-----Original Message-----
From: Yoshifumi Nishida [mailto:[email-masked]] 
Sent: Tuesday, July 30, 2013 8:35 AM
To: Krishna Khanal
Cc: Christoph Paasch; multipathtcp
Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior

Hi,

packet 1 with MPCAP
packet 2 with MPCAP
packet 3 with MPCAP

--
Yoshifumi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 29 Jul 2013 23:44:08 -0700

Hi Krishna,

Yes. you're right. I don't say it's a good approach. I just say it
might improve a situation with simple trick.
You might be able to check which destinations have many fallbacks,
then actives it..
-
Yoshifumi