Re: [multipathtcp] Number of DSS to store

[Olivier Bonaventure <[e-mail]>]

Anumita,

> 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.

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