TCP slow start/congestion avoidance - question

Hello!

I was reading RFCs (2001+2581) and also TCP/IP Illustrated and there is
one thing I dont get...
When congestion is obesrved during "slow start", TCP will set 'ssthresh'
usually to 1/2 of current cwin and what then?
OK, lets say that we observed congestion during "slow start" when cwin
was 32. Now we have ssthresh=16 and cwin=16 and "congestion avoidanve"
takes control. So it will be inreasing cwin by each ACK, but sooner or
later it will reach cwin=32 (or smaller) and wtah then? Is it going to
modify 'ssthresh' (cwnd/2) again and slow down to it? And later? Again
will reach this point and slows down to half speed?

-josh

josh <pljosh_at_poczta_neostrada_pl_@.> wrote in message news:<c9pi7n$edu$(E-Mail Removed)>...
> Hello!
>
> I was reading RFCs (2001+2581) and also TCP/IP Illustrated and there is
> one thing I dont get...
> When congestion is obesrved during "slow start", TCP will set 'ssthresh'
> usually to 1/2 of current cwin and what then?

I couldn't locate any "usually 1/2" ... where should I look?

> OK, lets say that we observed congestion during "slow start" when cwin
> was 32. Now we have ssthresh=16 and cwin=16 and "congestion avoidanve"
> takes control. ...

> ... So it will be inreasing cwin by each ACK, but sooner or
> later it will reach cwin=32 (or smaller) and wtah then? ...

What "it" are you referring to? Sender?

> Is it going to modify 'ssthresh' (cwnd/2) again and slow down to it?

Why would it without an indication from the receiver? The sender
already "knows" what he is prepared to send as a "max window"...
SENDER MAXIMUM SEGMENT SIZE (SMSS). ssthresh simply indicates _when_
to swicth from slow start to congestion avoidance -- not what sizes to
actually use.

> And later? Again will reach this point and slows down to half speed?
>
> -josh

I think you are generalzing from a specific example presented by
Stevens ... ? Where slow start was, in fact, avoided? Which example
are you referring to -- I quit at "21.7 Fast Retransmit and Fast
Recovery Algorithms".

Slow start and congestion avoidance can and do interact in a number of
ways -- a few are "required" (MUST or SHOULD) and the others are
varied (MAY) ...

I am not aware of any "required" means of (re)calculating ssthresh
except...
From rfc 2581:
When a TCP sender detects segment loss using the _retransmission
timer_, the value of ssthresh MUST be set to no more than the value
given in equation 3:

ssthresh = max (FlightSize / 2, 2*SMSS) (3)

As discussed above, FlightSize is the amount of outstanding data in
the network.

Implementation Note: an easy mistake to make is to simply use cwnd,
rather than FlightSize, which in some implementations may
incidentally increase well beyond rwnd.

From rfc 2581:
The congestion window (cwnd) is a sender-side limit on the amount of
data the sender can transmit into the network before receiving an
acknowledgment (ACK), while the receiver's advertised window (rwnd) is
a receiver-side limit on the amount of outstanding data. _The minimum
of cwnd and rwnd governs data transmission._

Congestion control has evolved a lot since Stevens Vol 1 with some
accepted, some not. You might want to check out this site to search
"ssthresh" and "smss" -- I prefer being able to search the returned
html to text files ;-)
http://www.faqs.org/rfcs/
and this paper:
http://www.acm.org/sigs/sigcomm/sigc...apers/hoe.html

You have to be very careful when reading these formulas, etc. as they
almost always refer to a _specific_ set of "triggers" -- I have a
terrible time keeping them straight, so have given up trying to hold
'em in my head ;-) Makes my head hurt just to think about it ...
|[:-(

hth,
prg
email above disabled

U¿ytkownik P Gentry napisa³:
> josh <pljosh_at_poczta_neostrada_pl_@.> wrote in message news:<c9pi7n$edu$(E-Mail Removed)>...
>
>>Hello!
>>
>>I was reading RFCs (2001+2581) and also TCP/IP Illustrated and there is
>>one thing I dont get...
>>When congestion is obesrved during "slow start", TCP will set 'ssthresh'
>>usually to 1/2 of current cwin and what then?
>
>
> I couldn't locate any "usually 1/2" ... where should I look?

here:
ssthresh = max (FlightSize / 2, 2*SMSS) (3)

which usually means: max(min(cwnd,rwnd)/2, 2)
but it doesnt matter anyway for now... it is ennough that ssthresh will
be set to some value between 0 and x, where x is amount of data that was
send and lost.

>>OK, lets say that we observed congestion during "slow start" when cwin
>>was 32. Now we have ssthresh=16 and cwin=16 and "congestion avoidanve"
>>takes control. ...
>>... So it will be inreasing cwin by each ACK, but sooner or
>>later it will reach cwin=32 (or smaller) and wtah then? ...
>
> What "it" are you referring to? Sender?

Sure - sender is the only one who controlls 'cwin'.
I mean: cwin is sender's limit, rwin is reciver's limit, and sender must
not send more than min(rwin,cwin) in any given moment.

>
>>Is it going to modify 'ssthresh' (cwnd/2) again and slow down to it?

> Why would it without an indication from the receiver? The sender
> already "knows" what he is prepared to send as a "max window"...
> SENDER MAXIMUM SEGMENT SIZE (SMSS). ssthresh simply indicates _when_
> to swicth from slow start to congestion avoidance -- not what sizes to
> actually use.
>
>>And later? Again will reach this point and slows down to half speed?
>>

In this part i was asking for such a situation:
there is "slow start" and at some value of cwin (for example: 32) sender
is figuring out that there are lost of packets. So it will set ssthresh
but my question is: what is happening then?

And similar situation:
there is "congestion avoidance" and at some value of cwin (for example
28) sender is figuring out that there are lost of packets. So will be
done later?


> I think you are generalzing from a specific example presented by
> Stevens ... ? Where slow start was, in fact, avoided? Which example
> are you referring to -- I quit at "21.7 Fast Retransmit and Fast
> Recovery Algorithms".

Hmm... I am not sure if I am generalizing something. I am just curious
what is happening before and after this particular example presentet by
Stevens at figure 21.8 on page 312 of TCP/IP Illustrated, Vol 1.

> hth,
> prg
> email above disabled

Thanks for response.

-josh

was:
between 0 and x

should be:
between 2*SMSS and x

in:
> which usually means: max(min(cwnd,rwnd)/2, 2)
> but it doesnt matter anyway for now... it is ennough that ssthresh will
> be set to some value between !! 2*SMSS !! and x, where x is amount of data that was
> send and lost.

josh <pljosh_at_poczta_neostrada_pl_@.> wrote in message news:<c9sj5o$c59$(E-Mail Removed)>...
> U¿ytkownik P Gentry napisa³:
> > josh <pljosh_at_poczta_neostrada_pl_@.> wrote in message news:<c9pi7n$edu$(E-Mail Removed)>...
> >
> >>Hello!
> >>
> >>I was reading RFCs (2001+2581) and also TCP/IP Illustrated and there is
> >>one thing I dont get...
> >>When congestion is obesrved during "slow start", TCP will set 'ssthresh'
> >>usually to 1/2 of current cwin and what then?
> >
> >
> > I couldn't locate any "usually 1/2" ... where should I look?
>
> here:
> ssthresh = max (FlightSize / 2, 2*SMSS) (3)
>
> which usually means: max(min(cwnd,rwnd)/2, 2)
> but it doesnt matter anyway for now... it is ennough that ssthresh will
> be set to some value between 0 and x, where x is amount of data that was
> send and lost.
>
> >>OK, lets say that we observed congestion during "slow start" when cwin
> >>was 32. Now we have ssthresh=16 and cwin=16 and "congestion avoidanve"
> >>takes control. ...
> >>... So it will be inreasing cwin by each ACK, but sooner or
> >>later it will reach cwin=32 (or smaller) and wtah then? ...
> >
> > What "it" are you referring to? Sender?
>
> Sure - sender is the only one who controlls 'cwin'.
> I mean: cwin is sender's limit, rwin is reciver's limit, and sender must
> not send more than min(rwin,cwin) in any given moment.
>
> >
> >>Is it going to modify 'ssthresh' (cwnd/2) again and slow down to it?
>
> > Why would it without an indication from the receiver? The sender
> > already "knows" what he is prepared to send as a "max window"...
> > SENDER MAXIMUM SEGMENT SIZE (SMSS). ssthresh simply indicates _when_
> > to swicth from slow start to congestion avoidance -- not what sizes to
> > actually use.
> >
> >>And later? Again will reach this point and slows down to half speed?
> >>
>
> In this part i was asking for such a situation:
> there is "slow start" and at some value of cwin (for example: 32) sender
> is figuring out that there are lost of packets. So it will set ssthresh
> but my question is: what is happening then?
>
> And similar situation:
> there is "congestion avoidance" and at some value of cwin (for example
> 28) sender is figuring out that there are lost of packets. So will be
> done later?
>
>
> > I think you are generalzing from a specific example presented by
> > Stevens ... ? Where slow start was, in fact, avoided? Which example
> > are you referring to -- I quit at "21.7 Fast Retransmit and Fast
> > Recovery Algorithms".
>
> Hmm... I am not sure if I am generalizing something. I am just curious
> what is happening before and after this particular example presentet by
> Stevens at figure 21.8 on page 312 of TCP/IP Illustrated, Vol 1.
>
> > hth,
> > prg
> > email above disabled
>
> Thanks for response.
>
> -josh

I was just checking into the "particulars" of your question -- had a
feeling they were along these lines but wasn't sure ...

In most respects, I _think_ the question you pose is a "corner case"
where the specs (MUST) haven't settled on a solution -- ie., there is
a bit of wiggle-room for each implementation to do as it chooses. My
guess is that this is because ssthresh is not a _determinative_
variable like the cwnd and rwnd -- but this is only a guess.

I do know from reading some other rfcs that this particular case is
very thorny -- especially at gigabit rates. In fact, that is why your
question caught my eye, as at these rates your case can (currently
does?) incur very high overhead to "correct" -- thus jumbo frames but
no standard yet in a sense:-(

In the current state of things, I believe everyone depends on the ACK
seq #'s to determine the # of bytes sent "good" and simply retransmits
all bytes from the last ACK'd good+1 and tries like hell to avoid the
receiver sending a rwnd(0) back -- ie., there is no clear way to
determine the _cause_ of the disruption. In effect, we're working via
"rules of thumb" rather than "perfect knowledge" of the current state
of the network.

In any case, your close reading and sharp questioning has me wondering
"just what happens" too ... hmmm ... Will have to think through the
variables/timers involved that would trigger this sequence.

I've probably not noted some of these details closely because their
answer/solution resides with those that write the stack -- ie., I
don't think there's anything you can do from userland to effect the
course of events or even clearly to discern their effects :-( Driver
writers maybe?

wish I had a better answer for both of us,
prg
email above disabled

Uzytkownik P Gentry napisal:

> I was just checking into the "particulars" of your question -- had a
> feeling they were along these lines but wasn't sure ...
>
> In most respects, I _think_ the question you pose is a "corner case"
> where the specs (MUST) haven't settled on a solution -- ie., there is
> a bit of wiggle-room for each implementation to do as it chooses. My
> guess is that this is because ssthresh is not a _determinative_
> variable like the cwnd and rwnd -- but this is only a guess.
>
> I do know from reading some other rfcs that this particular case is
> very thorny -- especially at gigabit rates. In fact, that is why your
> question caught my eye, as at these rates your case can (currently
> does?) incur very high overhead to "correct" -- thus jumbo frames but
> no standard yet in a sense:-(
>
> In the current state of things, I believe everyone depends on the ACK
> seq #'s to determine the # of bytes sent "good" and simply retransmits
> all bytes from the last ACK'd good+1 and tries like hell to avoid the
> receiver sending a rwnd(0) back -- ie., there is no clear way to
> determine the _cause_ of the disruption. In effect, we're working via
> "rules of thumb" rather than "perfect knowledge" of the current state
> of the network.
>
> In any case, your close reading and sharp questioning has me wondering
> "just what happens" too ... hmmm ... Will have to think through the
> variables/timers involved that would trigger this sequence.
>
> I've probably not noted some of these details closely because their
> answer/solution resides with those that write the stack -- ie., I
> don't think there's anything you can do from userland to effect the
> course of events or even clearly to discern their effects :-( Driver
> writers maybe?
>
> wish I had a better answer for both of us,
> prg
> email above disabled

Heh - i didn't know it is such a deep question. Actually there is no
special need for me to know such a details. I am just writing my thesis
about linux traffic control and had to finish the part about TCP
build-in routines. So anyway - I just figured out that it is ennough for
me to know that TCP will always try to send data as fast as it can
trying not to saturate the network and that there are such a things like
'slow start', 'congestion avoidance' and other algorithms that are doing
their job well

-josh

P.S.: For about 3 hours I am trying to figure out my next problem
concerning 'priomap' in pfifo_fast and PRIO qdiscs
....so I am inviting you to my next thread "priomap unclear"