Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-immediately-02: 19th March 2013

[Anna Brunstrom <[e-mail]>]

Hi Michael and all,

I have also read and support this draft.

In relation to the use case discussion I think that a potential use 
case, related to but not fully covered by RTO restart, is thin stream 
applications that send messages at a low rate (perhaps gaming control 
packets over a RTCWeb data channel or something similar). Here the I-bit 
could be useful to avoid delayed ACKs infalting the RTO and leading to 
reduced performance if a later message is lost.

Perhaps adding such a use case under 4.1 could be good to show that 
there are more than one use case also at the application level? Section 
4.1 almost gives the impression that the application use case for 
setting the I-bit is connected to the SCTP_SENDER_DRY_EVENT 
notification, which I guess is meant only as an example.

Another detail on 4.1. When from the perspective of the application, 
would it be better to say that the application sets the I-bit for a 
message (rather than the last DATA chunk of a message) as it is not 
really aware of the split into chunks?

Nit. In section 7, I guess "the SCTP_SACK_IMMEDIATELY flags can be set 
in the sinfo_flags field" should be "the SCTP_SACK_IMMEDIATELY flag ...".

BR,
Anna

On 2013-04-04 22:20, Michael Tuexen wrote:
> On Apr 4, 2013, at 9:57 PM, Michael Welzl wrote:
>
>> On Apr 4, 2013, at 9:34 PM, Michael Tuexen <[e-mail]> wrote:
>>
>>> On Apr 3, 2013, at 11:42 AM, Michael Welzl wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On 2. apr. 2013, at 10:58, Michael Tuexen wrote:
>>>>
>>>>> On Apr 2, 2013, at 10:15 AM, Michael Welzl wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have read this draft and support it.
>>>>>>
>>>>>> Regarding the issue below:
>>>>>>
>>>>>>
>>>>>> On 2. apr. 2013, at 09:27, Michael Tuexen wrote:
>>>>>>
>>>>>>> On Apr 2, 2013, at 8:29 AM, Yoshifumi Nishida wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I support this draft.
>>>>>>>> Some minor questions I have are related to the following rule in the draft.
>>>>>>>> "the sending of a DATA chunk fills the congestion or receiver window."
>>>>>>>>
>>>>>>>> 1: I am personally curious about how much benefit we can get by this.
>>>>>>>> If there's an analysis on this, I will want to see it in the reference.
>>>>>>> Hi Yoshifumi,
>>>>>>>
>>>>>>> some simulation results are available at:
>>>>>>> Improving the Acknowledgment Handling of SCTP
>>>>>>> Rüngeler, I.; Tüxen, M.; Rathgeb, E. P.
>>>>>>> Proceedings of the 4th International Conference on Digital Society (ICDS 2010), February 2010.
>>>>>>>> 2: Because this rule will be checked on every packet transmission, I
>>>>>>>> would like to know if the draft suggests to set I-bit everytime we
>>>>>>>> have a chance or there might be a case where we shouldn't.
>>>>>>> The sender could do it to switch off delayed SACK. However, this
>>>>>>> might not be useful. Therefore, as stated, the sender should set it,
>>>>>>> when he is waiting for an SACK.
>>>>>> Could there be a way to phrase this in that style, to also make it more general than "a DATA chunk fills the congestion or receiver window" ?
>>>>> Besides the very generic statement
>>>>> (Whenever the sender of a DATA chunk can benefit from the
>>>>> corresponding SACK chunk being sent back without delay...)
>>>>> the ID lists some concrete situations (not a complete list).
>>>>> I'm open to add another one, if you can provide some text...
>>>> See below -
>>>>
>>>>
>>>>>> I'm thinking about the case that draft-ietf-tcpm-rtorestart-00 addresses, of an application-limited sender that only has one SACK to expect and, in case it doesn't arrive, only a timeout to rely upon. Unless I'm missing some SCTP-specific detail here, it should also be beneficial to SACK early in this case (see fig. 1 in our draft).
>>>>> I'm not sure how the I-bit helps. I think you are focussing on retransmissions in case of packet drops.
>>>>> Assume that the RTO is larger than the RTT + SACK.delay (if not, it is a mis-configuation, in
>>>>> which setting the I-bit allows the sender to work around the problem), then one of two things happen:
>>>>> * the packet is dropped and there is no SACK acking it. The sender will retransmit after RTO.
>>>>> * the packet arrives and the corresponding SACK will arrive after an RTT or RTT + SACK.delay.
>>>>> In both cases, no retransmission will happen.
>>>>>
>>>>> Am I missing something?
>>>>>> This case would be covered by "when it is waiting for a SACK" but not by "fills the congestion or receiver window" (because both of these windows may be much larger than what the sender really transmits).
>>>>> I'm open for adding another scenario, where it helps. However, I did not understand you case
>>>>> above...
>>>> My apologies, there are two issues with what I wrote:
>>>> 1) writing about only one single packet was of course misleading - yes it is about this packet (the case where it's dropped), but it really has to do with the ACK of the preceding packet.
>>>> 2) because of 1), in fact it was wrong to say that "this case would be covered by 'when it is waiting for a SACK' " because it's the preceding packet that would have to have the I-bit set. That makes it harder to come up with text, but I'll give it a try anyway. I suggest the following:
>>>>
>>>> ***
>>>> - leave the generic statement (Whenever the sender of a DATA chunk can benefit from the
>>>> corresponding SACK chunk being sent back without delay...) as it is
>>>> - in section 4.2, insert the following paragraph:
>>>>
>>>> When a sender receives a SACK chunk, it re-arms the RTO timer, and the time at which this happens if affected by a delayed SACK chunk. If the last packet in a send window is lost, it will therefore be retransmitted later if the SACK chunk that was caused by the DATA chunk just before it is delayed. This can be avoided by setting the I-bit on the penultimate DATA chunk of the send window.
>>>>
>>>> Item for section 5.1:
>>>> - The DATA chunk is known to be the penultimate DATA chunk of the send window.
>>>> ***
>>>>
>>>> The tricky bit here is the application-limited case. In case of a greedy sender, the "penultimate DATA chunk of a send window" is the DATA chunk just before the one that fills the congestion or receiver window, or the last DATA chunk altogether before the association is shut down. But in the application-limited case, one can never be sure how long an application pause is going to last... in my text above, I decided to leave this open by just saying "of the send window". This is perhaps not good - if you can fix this great, if you'd rather not even bother, just leave it out and forget it, that's fine by me too  :-)   it was just a suggestion. Anyway it's covered by the nice CFP-style phrase in your text that says: "Reasons for setting the I-bit include, but are not limited to, the following"  :-)
>>>>
>>>> I hope I have made myself clear enough. If not, please do take a quick look at fig. 1 of http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-00 which probably explains it better.
>>> Hi Michael,
>>>
>>> OK I understand the point. Just to double check: If draft-ietf-tcpm-rtorestart is used, the above is not necessary, right?
>>> If that is right, wouldn't the right solution be to implement draft-ietf-tcpm-rtorestart-00? In both cases it would be
>>> a sender side modification?
>> Yes and yes   :-)
> OK. Then I would prefer to leave it out of this document since it is neither the right solution
> nor easy to implement (at least the application limited case).
>
> Best regards
> Michael
>> Cheers,
>> Michael
>>
>>