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

[Michael Tüxen <[e-mail]>]

Hi Jana,

thank you very much for your review. See my comments in-line.

Best regards
Michael

On Sep 7, 2011, at 8:02 PM, 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).
DTLS is only an example...
Maybe it is better to describe how it is actually used by protocols like DTLS.

* You send a message setting the SCTP_SACK_IMMEDIATELY flag.
* You enable the SCTP_SENDER_DRY_EVENT as described in
  http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-31#section-6.1.9
* You wait for the SCTP_SENDER_DRY_EVENT to come up from the SCTP stack.

You can do the above without the SCTP_SACK_IMMEDIATELY, but you might need to wait
for the additional time the peer delays the SACK.

If this makes it clearer to you, I can add such a text to the introduction.
> 
> 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 
Again, DTLS is only an example. When porting SSH to SCTP, we need again the pattern above and
have to wait for the delayed SACK for no good reason. I'm pretty sure, when porting other
protocol to SCTP, 
> 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 
This is not so easy: In FreeBSD we
* consider also some overhead as in flight to avoid overrunning the receiver.
  Testing has shown that if the peer announces 10000 bytes, it *does* matter if
  you send him 10000 messages of 1 byte or 1 message of 10000 bytes.
* we have other limits: For example we limit the number of chunks being
  in flight. The receiver doesn't know this. So this situation can only
  be known by the sender.
So the point is the first sentence of section 4.1:

Whenever the sender of a DATA chunk can benefit from the
corresponding SACK chunk being sent back without delay, the sender
MAY set the I-bit in the DATA chunk header.

> app, the sending transport will have a full cwnd, and will therefore probably set the I-bit on every other transmitted packet or so.
Maybe. But that is not a problem. If the receiver has used the socket option to send a SACK
for each packet, it will already happen.
Since SCTP does ABC, this doesn't hurt.

Even if the sender sets the I-Bit arbitrary, it should no drive the protocol into
a new situation.
> 
> 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 
This is an interesting point: It depends who is asked. Some do it more frequently. However,
I don't think the I-Bit is used exclusively for DTLS. See the above pattern.
I think it is bad to wait for something that doesn't occur.
> 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 
Are the semantics clearer when looking at the above pattern?
> 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 
I don't see how this interacts with the chunking. It will be the same
as if the SACK timer is already running or the receiver has switched of
the delay sacked. Same for the CC. Since SCTP uses ABC, it doesn't matter
if you SACK every other or every SACK. Again: This is already happening now,
if the receiver sets the SACK frequency to 1, using the SCTP_DELAYED_SACK
socket option. So there is nothing new. At least, I can't see it.
> 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.
I think the behavior is predictable:
* It is clearly specified, which DATA chunk has the I-Bit set, if you provide the SCTP_SACK_IMMEDIATELY
  flag.
* It is clearly specified, how the receiver behaves if it receives a DATA chunk
  with the I-Bit set.
* It is clearly specified how the SCTP_SENDER_DRY_EVENT works.

Maybe I'm overlooking something, but for me it is clearly specified.
> 
> 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.
If it is triggered by the application, I would guess that you want it to do in
combination with the SCTP_SENDER_DRY_EVENT. I can add text to describe that.

If it is triggered from the kernel, it is described by the first sentence
of section 4.1.

Please note that the only point we need to standardize is
* the bit
* the receiver side procedure

For the receiver it doesn't matter why it is set. So we don't need an
exhaustive list. It is similar to sending the FORWARD-TSN chunk:
You need to specify the interaction, but not when you want to use it.
> 
> 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
>