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

[Gorry Fairhurst <[e-mail]>]

  Indeed, the biggest problem I am facing as a Chair is a clear 
indication of need and usefulness.

To proceed the authors will need to get this clarified.

Gorry

On 07/09/2011 19:02, Janardhan Iyengar wrote:
> 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
>>
>>
>