Subject: [multipathtcp] receive window considerations

From: Padma Bhooma <[email-masked]>
Date: Fri, 14 Aug 2009 11:45:56 -0700

Hello,

I have a couple of questions about receive window management across  
multiple sub flows. The draft (draft-ford-mptcp-multiaddressed-01)  
says that receive window will be shared across the sub flows. If  some  
of the later sub flows (in sequence space) fill up the receiver's  
socket buffer, the receive window seen by earlier sub flows will  
become smaller. This might increase the delay seen by an application.

How will fragmentation in socket buffer be handled? Will the receive  
window be the total un-filled memory left or will it be the next hole  
to be filled?

I am sorry if I missed any discussion related to this and I will  
appreciate any pointer to such discussion.

Thanks,
Padma

---

From: Costin Raiciu <[email-masked]>
Date: Sat, 15 Aug 2009 21:00:50 +0300

Hi,

I am not sure I completely understand your question(s), but here's  
the way I see receiver window issues.

The receiver window specifies at connection level how much data the  
receiver is willing to accept past the (data level )cumulative ack.  
If data is received that is not in order, this cannot be passed to  
the application until earlier data arrives; this means that if there  
is a hole, the receive window will not move on. It will only move on  
when the (data level) cumulative ack moves on. This single receive  
window, computed probably from the amount of memory
available to the socket (but never shrank once offered, as in Linux  
kernel implementations), is advertised to the remote end on all  
subflows.

Each subflow now carries a receive window that makes sense at  
connection level, and that tells the receiver what to accept. How  
(and if) this same receive window is used to *validate* subflow  
sequence numbers is open to discussion.
Clearly, on any given subflow, the sender must not send more data  
than allowed by the connection level receive window.This means we can  
use the same receive window to drop packets with out-of-window  
subflow sequence number.

Cheers
Costin

On 14 Aug 2009, at 21:45, Padma Bhooma wrote:

> says that receive window will be shared across the sub flows. If   
> some of the later sub flows (in sequence space) fill up the  
> receiver's socket buffer, the receive window seen by earlier sub  
> flows will become smaller. This might increase the delay seen by an  
> application.
>
> How will fragmentation in socket buffer be handled? Will the  
> receive window be the total un-filled memory left or will it be the  
> next hole to be filled?
>
> Padma_______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Padma Bhooma <[email-masked]>
Date: Fri, 21 Aug 2009 06:48:47 -0700

Hi,

Thanks for clarifying this for me. Since the cumulative-ack was  
described as sub flow level ack, I was not clear about receive window.  
But it is possible to compute the data level cumulative ack and make  
sense out of the receive window.

I think one question is to decide how to stripe the available data in  
the sender's buffer across multiple sub flows. Will it be one packet  
worth of data at a time or will the socket buffer be divided across  
the sub flows based on the bandwidth available on that connection.  
Both of them will work but I am just curious to know if you have  
decided on one of these two methods or some other method..

Thanks,
Padma

On Aug 15, 2009, at 11:00 AM, Costin Raiciu wrote:

> than allowed by the connection level receive window.This means we  
> can use the same receive window to drop packets with out-of-window  
> subflow sequence number.
>
> Cheers
> Costin
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Aug 2009 17:05:44 +0200

On 14 aug 2009, at 20:45, Padma Bhooma wrote:

> window be the total un-filled memory left or will it be the next  
> hole to be filled?

The receive buffer makes it possible for the sender to send data for  
at least some time while the application isn't accepting the data.  
Because a stream protocol like TCP requires the data to be delivered  
to the application in the same order as it was sent, the receive  
buffer will fill up when a segment is lost. If n was lost, n+1, n 
+2, ... can't be delivered to the application until n has been  
retransmitted successfully.

In order to maintain compatibility with existing applications, the  
above must be true for a multipath TCP the same way it is for existing  
TCP.

The problem with multipath TCP is that if one path has a loss, this  
will create a hole in the data stream so subsequent segments have to  
remain in the receive buffer. If the missing segment isn't  
retransmitted quickly, the receive buffer will fill up and the entire  
session will stall, even though one or more subflows are progressing  
without trouble.

For normal losses fast retransmit will solve the problem for the most  
part, of if not fast retransmit, then a normal retransmission after a  
small delay. However, if one path is broken the session will enter a  
state where there is very little progress until the broken path is  
taken down.

To avoid any slowdowns because of all of this, the one-ended MPTCP  
draft has a "slow retransmit" algorithm that retransmits the missing  
data before the receive buffer fills up.

http://tools.ietf.org/html/draft-van-beijnum-1e-mp-tcp-00