Re: [Lksctp-developers] [RFC] [PATCH] sctp: implement sctp association probing module

[Frank S. <fra...@we...>]

> > And the second thing is:
> > ...
> > 0.022586 d40a5000 54079 17603  1500     5632    29 *192.168.1.101  1    41784    50000    42108        0     1500
> > 0.022811 d40a5000 54079 17603  1500     8068    28 *192.168.1.101  1    43284    50000    40040        0     1500
> > 0.022908 d40a5000 54079 17603  1500    11156    26 *192.168.1.101  1    43284    50000    37136        0     1500
> > 0.023003 d40a5000 54079 17603  1500    14060    24 *192.168.1.101  1    43284    50000    34232        0     1500
> > 0.023097 d40a5000 54079 17603  1500    16964    22 *192.168.1.101  1    43284    50000    31328        0     1500
> > ...
> > The cwnd increase only to 43284 bytes in maximum it never grows about 50000 bytes - it is constant at 43284!!! I think there is something wrong. What's happen? Is this a bug in the value? I can't understand this behaviour.
> > I take a look in the rfc 4960 but I can't find a reason for it, when the value is correct.
> > Perhaps somebody can help me to understand the slow start?
> 
> This is most likely triggered by burst limiter.  This means that a SACK would
> allow more DATA to be sent then a max_burst limit would allow.  Thus we stop at
> max_burst and the congestion window never fills up.
> 
Hmm...this is very hard to understand, but I hope you can help me and say me, if I understand your answer correct.
I'm sure that's right, what you say, but I try follow your words.

1.) Why SACK allow more DATA than max_burst_limit? In rfc 4960 section 6.1.D, it will be limited of max_burst after a SACK, or not?
Or did you mean, in linux kernel is this limited but it is a MAY-feature in the rfc?

2.) And why the congestion window can never fill up?
     There are two possibilites in 6.1.D for limitation:
     a) if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +  Max.Burst*MTU
     b) Or it MAY be applied by strictly limiting the number of packets emitted by the output routine.

    If in linux kernel 2b is implemented, it can be in theoretical more than cwnd bytes, so I think in kernel is implemented 2a, correct?

> We used to drop the congestion window to 6000 when that happen.  So you'd see
> a window in the 40K range that suddenly drops to 6000 and has to grow again.
> Some people find this behavior a little better.

3.) You mean here, that congestion avoidance will never execute in the first slow start phase?
4.) So it can be only a problem of retransmitting, sack and other errors but not that cwnd will be greater than ssthresh, correct?
5.) Because if an error occur the ssthresh will be set immediatly to 6000 and cwnd to 1500 bytes, right?
And than I see the congestion avoidance behaviour because it grows about 6000 bytes to the rwnd value from the init packet.

The slow-start algorithm isn't really easy to understand for me, but I think it is a main-feature of sctp and therefore I want to understand it exactly.

Thanks for your help!!!

Frank
________________________________________________________________
Nur noch bis 31.01.2010: DSL Komplettpaket für 16,99 Euro/mtl.!*
http://produkte.web.de/go/02/