slow start triggered if recv window full on packet loss? - TCP-IP

This is a discussion on slow start triggered if recv window full on packet loss? - TCP-IP ; Hi I'm not sure if this is off topic for this mailing list I'm trying to understand one behaviour of TCP I cannot explain analyzing some traces, I find that when there is a fast-retransmit, during that period if the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: slow start triggered if recv window full on packet loss?

  1. slow start triggered if recv window full on packet loss?

    Hi

    I'm not sure if this is off topic for this mailing list

    I'm trying to understand one behaviour of TCP I cannot explain

    analyzing some traces, I find that when there is a fast-retransmit,
    during
    that period if the receive window is filled, when the sender receives
    a window
    update and resumes the sending activity, it resumes using slow start,
    or that is what it looks like:

    http://sites.google.com/site/despista000/index-html (tcptrace
    plot)

    whilst I would expect the tcp sender resumes with the congestion
    window it had.

    does my description matches the behaviour shown in the plot?

    comments/references appreciated

    Thanks


  2. Re: slow start triggered if recv window full on packet loss?

    ulisses.alonso@gmail.com wrote:

    > I'm not sure if this is off topic for this mailing list


    > I'm trying to understand one behaviour of TCP I cannot explain
    > analyzing some traces, I find that when there is a fast-retransmit,
    > during that period if the receive window is filled, when the sender
    > receives a window update and resumes the sending activity, it
    > resumes using slow start, or that is what it looks like:


    > http://sites.google.com/site/despista000/index-html (tcptrace
    > plot)


    > whilst I would expect the tcp sender resumes with the congestion
    > window it had.


    > does my description matches the behaviour shown in the plot?


    How long does the window remain full? Is it full for at least one RTT
    or more? If so, then it could be that the stack is set to use slow
    start after idle and the length of time without sending any new data
    has exceeded the "idle timeout" to trigger slowstart. You might see
    if the stack you are using has a configuration setting to disable
    slowstart after idle and see if the behaviour persists.

    That is though just a guess.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread