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

[Michael Tuexen <[e-mail]>]

On Aug 23, 2011, at 9:40 AM, Kacheong Poon wrote:
> On 08/23/11 01:29 AM, Michael Tüxen wrote:
> 
>> 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.
> 
> 
> What is the rationale of "optimizing" the closing of an
> association?  An app should not need to be involved in
> the shutdown sequence.  For example, an app just call
> close() and can forget about the association.
That is the client side. Think about the server side.
This 200ms delay will require the server to keep the
assoc around for additional 200ms for just nothing.
If you have a server with lots of short living associations,
you might want to get rid of them as soon as possible.
> 
> 
>> 2. You need to wait for a possibly delayed SACK timer if
>>    you ware waiting for a SENDER_DRY event.
> 
> 
> Can you explain why this is actually important?
If an applications wants to make sure that everything is
received by the peer SCTP stack, it will enable the
subscribe to the sender dry event and wait for it.
If the peer is delaying the SACK for 200ms, it has to
wait RTT + 200ms instead of just the RTT. For small
RTTs this is a difference.
The is used for example in the DTLS handshake. The delays
can add up to 1 second.
> 
> 
>> 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.
> 
> 
> As Mark has pointed out, this is not a reason.  In fact,
> if the peer has an implementation or configuration
> problem, how can you be sure that the peer implements the
> quick ACK correctly?  Adding more features won't help fix
> misconfiguration or implementation error.  I'd argue that
> adding more features actually make things worse as things
> are getting even more complicated.  Quick ACK is going to
> hurt instead of helping at all.
Hmmm. At least in the scenarios I was able to look
at trace files, the receiver was running Linux, which
supports the I-Bit. So getting it implemented was
not a problem (FreeBSD also supports it, Solaris don't,
I guess).
I agree, fixing the configuration problem is the solution.
But in the traces contained the following pattern:
Transmit data, retransmit it, get a SACK with a dup report.
Over and over. So the sender can detect that there is
some problem, could set the I-bit and at least reduce the
traffic on the network. It can also notify the user that
there is a problem.
> 
> 
>> As said above: This only helps if the Nagle algorithm is
>> involved.
> 
> 
> But it seems to be the single reasonable use of this
> mechanism given so far.
> 
> 
>> 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.
> 
> 
> I think you can search the tcpm or the old tcp-impl
> mailing list.  IMHO, it is just a simple implementation
> issue which does not really need an ID...
... OK. So simple that it was missed in the SCTP implementation
of BSD, I guess the same for Linux, and assume that Solaris does
it right...
Just to get it clear:
You don't delay a DATA chunk if only the E-bit is set, right?
> 
> 
>> "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.
> 
> 
> The performance issue mentioned can be solved by fixing
> the implementation.  It is not a protocol level issue.
I don't see this for the server side problem, for the
sender dry problem.
> 
> 
>> In particular taking the complexity of the change involved:
>> 1. For the receiver: trivial.
>> 2. For the sender: very easy.
> 
> 
> No, a transport protocol level change is never a trivial
> thing.  IMHO, this is a very dangerous thinking.  Anyway,
> just my $0.02.
I did the implementation in FreeBSD and saw the diff for Linux.
It is simple.
I agree with you, that one has to consider what a user can
do with it if it is not used as intended. But you can't be
worse than you can already be now by sending back a SACK
for each packet...

Best regards
Michael
> 
> 
> 
> -- 
> 
> 					K. Poon.
> 					[e-mail]
>