Subject: Re: [multipathtcp] Number of DSS to store

From: Christoph Paasch <[email-masked]>
Date: Wed, 01 Aug 2012 14:45:24 +0200

Hi Anumita & Alan,

On Tuesday 31 July 2012 21:44:35 Anumita Biswas wrote:
> A DSS option may not be sent with corresponding data if there isn't  enough
> tcp option space available such as due to the presence of SACK blocks.

Then the number of SACK-blocks could get reduced for the packet that needs to 
hold the DSS-option, or the SACK-blocks can be on a separate subflow-ack.

SACK-blocks don't necessarily need to be sent reliably. However, the DSS-
option has to be sent reliably. That's why it is good to couple it together 
with the data as delivery is thus guaranteed.

Alan, in your slides yesterday you said:
"A mapping for subflow seqno x MUST not be 
sent before the mappings for subflow seqno 
0 .. x-1 have been sent."

This will still force receivers to be able to store an uncertain number of 
DSS-mappings.

I believe we should say:
"A mapping, covering the subflow seqno's x to y MUST be sent on one of these 
segments."

That way the receiver only has to store one single DSS-mapping option per 
subflow.

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: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 20 Aug 2012 14:45:41 +0000

Quite honestly, I think we are getting lost in details. There is very little implementation and real-world experience with MPTCP. The simplest possible implementation sends ONE DSS per packet and does NO buffering of payload-w/o-mapping or mappings-w/o-payload and it may in fact provide proper operation in the vast majority of use cases. Exceptions should be based on real-world trials rather than speculation.

I agree with Christoph that on sender side, DSS should have priority over SACK blocks.

Georg

-----Original Message-----
From: Christoph Paasch [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 8:45 AM
To: Anumita Biswas
Cc: Alan Ford (alanford); Hampel, K Georg (K Georg); [email-masked]; Mahesh M; Ilpo Järvinen
Subject: Re: [multipathtcp] Number of DSS to store

Hi Anumita & Alan,

I believe we should say:

Cheers,
Christoph

---

From: Anumita Biswas <[email-masked]>
Date: Mon, 27 Aug 2012 11:33:51 -0700

Continuing on the topic of SACK and on Duplicate ACKs in general; 

Seeking clarification on this statement in the draft:

This changes
   the semantics of a duplicate ACK, these are usually only sent as a
   signal of a lost segment [9] in regular TCP.  Therefore, an MPTCP
   implementation receiving a duplicate ACK which contains an MPTCP
   option MUST NOT treat it as a signal of congestion.  Additionally, an
   MPTCP implementation SHOULD NOT send more than two duplicate ACKs in
   a row for signaling purposes, so as to ensure no middleboxes
   misinterpret this as a sign of congestion.

An MPTCP connection is likely going to be sending DSS option, Data ACK or Data ACK+DSS option in almost all packets. There is also sufficient discussion in the draft that indicate that one or more SACK block can fit in along with MPTCP options for most of the lower length DSS option variants. Indicating that one can send loss information along with MPTCP options.  But the above statement seemed to indicate that an MPTCP implementation receiving SACK in a packet along with MPTCP options must not treat it as a signal of congestion? Even if SACK was not negotiated, then the above statement indicates that Duplicate ACK should be sent as a separate segment not tied with a packet containing MPTCP options. There seems to be a contradiction between the above statement and say the section that discussed comibining SACK with MPTCP "Appendix A. Notes on use of TCP Options"?  

Or is the draft saying that one must treat the ACK field in a segment with MPTCP options not as a Duplicate ACK unless it contains SACK? I guess not. SACK should only complement Duplicate ACKs for indicating packet loss. Also, why would an implementation send more than two duplicate ACKs in a row unless it received two out of order packets in a row? 
 
Anumita.

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 27 Aug 2012 20:57:34 +0200

Anumita,

>    misinterpret this as a sign of congestion.

In this paragraph, "signaling purposes" means a duplicate ACK that is
only used to convey signalling information, ie. add address or remove
address.

During the data transfert, a duplicate ACK can contain the following
options :

- DSS
- MP_PRIO
- ADD_ADDR
- REMOVE_ADDR

A packet should only contain one DSS option but an MPTCP sender could
need to send several MP_PRIO, ADD_ADDR and REMOVE_ADDR. The paragraph
above was written to convey the idea that a duplicate ACK containing
these options should not trigger a congestion response. It seems that it
is a bit vague.

Would the following be clearer ?

"This changes the semantics of a duplicate ACK, these are usually only
sent as a signal of a lost segment [9] in regular TCP.  Therefore, an
MPTCP implementation receiving a duplicate ACK which contains the
MP_PRIO, ADD_ADDR or REMOVE_ADDR MPTCP option MUST NOT treat it as a
signal of congestion.  Additionally, an MPTCP implementation SHOULD NOT
send more than two duplicate ACKs in a row containing any of these three
options, so as to ensure no middleboxes misinterpret this as a sign of
congestion."

> An MPTCP connection is likely going to be sending DSS option, Data ACK
> or Data ACK+DSS option in almost all packets. There is also sufficient
> discussion in the draft that indicate that one or more SACK block can
> fit in along with MPTCP options for most of the lower length DSS option
> variants. Indicating that one can send loss information along with MPTCP
> options.  But the above statement seemed to indicate that an MPTCP
> implementation receiving SACK in a packet along with MPTCP options must
> not treat it as a signal of congestion? Even if SACK was not negotiated,
> then the above statement indicates that Duplicate ACK should be sent as
> a separate segment not tied with a packet containing MPTCP options.
> There seems to be a contradiction between the above statement and say
> the section that discussed comibining SACK with MPTCP "Appendix A. Notes
> on use of TCP Options"?  
> 
> Or is the draft saying that one must treat the ACK field in a segment
> with MPTCP options not as a Duplicate ACK unless it contains SACK? I
> guess not. SACK should only complement Duplicate ACKs for indicating
> packet loss. Also, why would an implementation send more than two
> duplicate ACKs in a row unless it received two out of order packets in a
> row? 

given the maximum length of the TCP options, when there are many SACKs
to report, an MPTCP implementation will have to chose between sending
SACKS and sending DSS/timestamp. Experimentation on the Internet is
needed to provide better implementation guidance in this case.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Anumita Biswas <[email-masked]>
Date: Mon, 27 Aug 2012 13:56:02 -0700

Olivier,

> options, so as to ensure no middleboxes misinterpret this as a sign of

Yes it is clearer. 

Thanks for the background also. Based on your comments, I went over the ADD_ADDR section also and found this:
As discussed earlier, however, an MPTCP
   implementation MUST NOT treat duplicate ACKs with any MPTCP option,
   with the exception of the DSS option, as indications of congestion
   [9], and an MPTCP implementation SHOULD NOT send more than two
   duplicate ACKs in a row for signaling purposes.

So the statement you have or perhaps even the above same statement can be placed in the more prominent location of Section 3. That way, MP_PRIO is not lost in the discussion.
I am assuming that MP_FAIL and MP_FASTCLOSE do not count as they signal termination.