Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item?

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

On Aug 22, 2011, at 6:52 PM, Kacheong Poon wrote:

> On 08/18/11 03:29 AM, Michael Tüxen wrote:
> 
>> Well, it depends. One particular example which comes up to my mind is
>> a simple request/response protocol running on top of SCTP.
>> Without pipelining the request (which is a good thing) you would
>> expect a rate of 1 response per RTT. What people run into is the
>> following. They test with small request size (small means that
>> it fits into an MTU) and get the expected behavior. When the request
>> size is larger than an MTU but smaller than two MTUs they get
>> 5 responses per second. Why? Because the SCTP stack sends the first
>> fragment to the peer, but delays sending the second fragment since
>> there is outstanding data due to the Nagle algorithm. The peer
>> does delay the SACK for 200ms. After sending the SACK, the second
>> fragment of the request gets sent and the response comes back.
>> The use can avoid this by:
>> 1. Disabling Nagle at all.
>> 2. Pipelining multiple requests.
>> The first is doable in any case, the second depends on the application.
>> However, the problem shows up only if the number of packets for the
>> request is even. Based on questions I got in the past, it is not
>> clear for the app writer to deal with these problems. So letting the
>> stack doing it seems useful.
>> We could also disable Nagle by default, but this is a bad idea I think.
> 
> 
> The above scenario was discussed in the context of TCP
> many years ago.  And AFAIK, most current TCP stacks do
> not have this issue anymore because the aforementioned
> way to implement Nagle algorithm has been determined to
> be the wrong way.  There is now no delay in sending the
> second TCP segment in the above scenario.  There is no
> need to modify the TCP protocol.  It is just an
> implementation issue.  If there is no issue in TCP, I
> guess there should also be no issue in SCTP.
So you are arguing that you can change the implementation
of the Nagle algorithm. That is correct. However, that
does not help in the other scenarios:
1. You need to delay the sending of a SHUTDOWN chunk until
   you received a SACK, which might be delayed.
2. You need to wait for a possibly delayed SACK timer if
   you ware waiting for a SENDER_DRY event.
3. You have no chance to deal with misconfigured peers
   in case the RTO values have been lowered on your side,
   but the SACK delay on the peer not. Unfortunately,
   I have seen this multiple times in production networks.
> 
> In fact, it is much easier to fix the SCTP implementation
> than to deploy a protocol level change.  The former
As said above: This only helps if the Nagle algorithm is
involved.
BTW: Is there a description (ID/RFC) available on the
Nagle algorithm you describe? At least on FreeBSD we
don't use that, but the old one.
> only requires the sender SCTP stack to be fixed while the
> latter requires both sides to support it plus app level
> changes.
> 
> Is a protocol level change really needed?
"Needed" is the crucial point here.
Needed in the sense that the protocol is broken without
the change: No.
Needed in the sense the the protocol shows a good performance
in some situations: Yes.
In particular taking the complexity of the change involved:
1. For the receiver: trivial.
2. For the sender: very easy.

Best regards
Michael

> 
> 
> -- 
> 
> 					K. Poon.
> 					[e-mail]
>