Loading ...
Sorry, an error occurred while loading the content.
 

Re: TCP problem

Expand Messages
  • Sam Manthorpe
    Hi, ... The retransmission timer should be switched off once the fast-retransmit phase is entered (e.g. line 869 of netinet/tcp_input.c of 4.4BSD), so this
    Message 1 of 6 , Feb 2, 1998
      Hi,

      > current BSD implementations set the ssthresh value to half the value of
      > the congestion window upon a timeout. Suppose a timeout happens due to a
      > retransmitted segment getting lost (or all its ACKs getting lost). As the
      > congestion window is normally inflated during fast recovery, the ssthresh value
      > upon a timeout will be set to 1/2 the inflated congestion window.
      > In particular, if the retransmitted segment gets lost, then the
      > congestion window will keep getting inflated (due to duplicate ACKs)
      > during fast recovery till it hits the advertised window. The ssthresh
      > would then be set to 1/2 the advertised window upon a timeout!

      The retransmission timer should be switched off once the fast-retransmit
      phase is entered (e.g. line 869 of netinet/tcp_input.c of 4.4BSD), so
      this problem should not occur, as far as I can see.

      Sam.

      ------------------------------------------------------------
      Sam Manthorpe, SGI. tel: (650) 933-2856 fax: (650) 932-1788
    • Mohit Aron
      ... This is incorrect. What if the retransmitted packet as well as all other ACKs in transit get lost ? There ll be no timer to tell TCP about this situation
      Message 2 of 6 , Feb 2, 1998
        >
        > The retransmission timer should be switched off once the fast-retransmit
        > phase is entered (e.g. line 869 of netinet/tcp_input.c of 4.4BSD), so
        > this problem should not occur, as far as I can see.
        >


        This is incorrect. What if the retransmitted packet as well as all other
        ACKs in transit get lost ? There'll be no timer to tell TCP about this
        situation and the connection would remain in this state forever.



        - Mohit Aron
        aron@...
      • Sam Manthorpe
        Hi, ... Yes, you re right, my mistake. Sam. ... Sam Manthorpe, SGI. tel: (650) 933-2856 fax: (650) 932-1788
        Message 3 of 6 , Feb 2, 1998
          Hi,

          > > The retransmission timer should be switched off once the fast-retransmit
          > > phase is entered (e.g. line 869 of netinet/tcp_input.c of 4.4BSD), so
          > > this problem should not occur, as far as I can see.
          > >
          > This is incorrect. What if the retransmitted packet as well as all other
          > ACKs in transit get lost ? There'll be no timer to tell TCP about this
          > situation and the connection would remain in this state forever.

          Yes, you're right, my mistake.

          Sam.

          ------------------------------------------------------------
          Sam Manthorpe, SGI. tel: (650) 933-2856 fax: (650) 932-1788
        • Mohit Aron
          ... It is generally accepted that the right behaviour after a timeout is to cut down the congestion window to 1 and do a slow-start. My concern primarily
          Message 4 of 6 , Feb 3, 1998
            > If this were to be the case ( congestion window getting inflated) then
            > network is capable of taking packets (dupacks tell me this ), and it only
            > a transiant that re-tansmitted packet got lost. So we can still continue
            > in fast recovery mode. May be one can retransmit the re-tansmitted packet
            > even after the timeout, if one is still sees that congestion window
            > getting inflated. Did I missed any thing Mohit ?
            >
            > Chetan S
            >


            It is generally accepted that the right behaviour after a timeout is to
            cut down the congestion window to 1 and do a slow-start. My concern primarily
            involvs the setting of ssthresh in this situation.




            - Mohit
          • Chetan Kumar
            On Thu, 29 Jan 1998, Mohit Aron wrote: * Hi, * current BSD implementations set the ssthresh value to half the value of * the congestion window upon a timeout.
            Message 5 of 6 , Feb 3, 1998
              On Thu, 29 Jan 1998, Mohit Aron wrote:

              *>Hi,
              *> current BSD implementations set the ssthresh value to half the value of
              *>the congestion window upon a timeout. Suppose a timeout happens due to a
              *>retransmitted segment getting lost (or all its ACKs getting lost). As the
              *>congestion window is normally inflated during fast recovery, the ssthresh value
              *>upon a timeout will be set to 1/2 the inflated congestion window. In
              *>particular, if the retransmitted segment gets lost, then the congestion window
              *>will keep getting inflated (due to duplicate ACKs) during fast recovery till it

              If this were to be the case ( congestion window getting inflated) then
              network is capable of taking packets (dupacks tell me this ), and it only
              a transiant that re-tansmitted packet got lost. So we can still continue
              in fast recovery mode. May be one can retransmit the re-tansmitted packet
              even after the timeout, if one is still sees that congestion window
              getting inflated. Did I missed any thing Mohit ?

              Chetan S
            Your message has been successfully submitted and would be delivered to recipients shortly.