Re: draft-tuexen-tsvwg-sctp-sack-immediately-07.txt

[Janardhan Iyengar <[e-mail]>]

Hi all,

My higher-order bit is that while the mechanism is straightforward, the most significant motivation for the I-bit as an independent mechanism, is performance during the DTLS re-keying.  The motivations for this bit were slim when I skimmed it first (-06), and are still lacking (in -07).

The I-bit makes sense in cases where the sender knows for sure that a SACK is not on the way back; I can see this for the DTLS case, but the other motivating cases are either less convincing or problematic.  When the receive window is closing, the receiver ought to know this, better than the sender -- why not simply specify this as a receive-side behavior?  Setting the I-bit when the cwnd is full is problematic; when the app is a bulk-transfer app, the sending transport will have a full cwnd, and will therefore probably set the I-bit on every other transmitted packet or so.

If I run with the most compelling case in the draft---an application asking for an immediate SACK, as with DTLS---the benefits are during DTLS re-keying, which, unless I'm reading the RFC wrong, is rare (RFC 4347, Sec. 4.1: "In practice, TLS implementations rarely rehandshake and we therefore do not expect this to be a problem.")  On the other hand, for the app-driven case, I cannot seem to get my head around the semantics of a sending *application* asking the receiving *transport* to SACK immediately.  I am not able to fully comprehend interactions with framing/chunking and with congestion control in the general case...  these interactions seem non-trivial in the general case, making the semantics of the API call unclear to an application.  What does it mean for an application to set the I-bit arbitrarily during a connection, when the current state of transmitted and acknowledged data is not visible to the application?  I'm not talking about what the worst case in terms of p
rotocol behavior is, I just don't think the application semantics of this mechanism are consistent or predictable, which is a problem.

FWIW, I'd be interested in reading more motivation and a more detailed "applicability" section which outlines how/where/when this bit is to be used.  It is easy to see that the bit is trivial to implement.  The part that is non-trivial is understanding what the bit really does under different circumstances, and that needs to be written out in more detail.

IMHO,
- jana


On 9/2/11 1:16 PM, Michael Tüxen wrote:
> Dear all,
>
> based on the recent feedback I've update the ID. See
> http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-sack-immediately-07
>
> The following issues were brought up during the discussion:
> * Using the I-Bit for mitigating Nagle effects is the wrong approach.
>    Resolution: Take it out.
> * Using the I-Bit for mitigating effects of misconfiguations seems
>    to create more confusion than it might help.
>    Resolution: Take it out.
> * Motivation is missing.
>    Resolution: Provide some text in the Introduction section.
> Please let me know if I overlooked anything or the motivation
> needs further improvements.
>
> Thank you very much for the feedback.
>
> Best regards
> Michael
>
>

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar