Re: [multipathtcp] Number of DSS to store

[Anumita Biswas <[e-mail]>]

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.
 


On Aug 20, 2012, at 7:45 AM, "Hampel, K Georg (K Georg)" <[e-mail]> wrote:

> 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:[e-mail]] 
> Sent: Wednesday, August 01, 2012 8:45 AM
> To: Anumita Biswas
> Cc: Alan Ford (alanford); Hampel, K Georg (K Georg); [e-mail]; Mahesh M; Ilpo Järvinen
> Subject: Re: [multipathtcp] Number of DSS to store
> 
> 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
> --