Re: timeout & retransmission of TCP packets

From: karthikeyan (thegreatkarthik_at_yahoo.co.in)
Date: 02/11/04

  • Next message: Cameron Kerr: "Re: Pipe closing" 
    Date: 10 Feb 2004 21:30:36 -0800

    sir,
     thks for ur reply Mr P Gentry
     If it is possible i will teach them in detail .
    Let me make myself fully equipped & let me guide them if there r really interested.
    Possibly i believe that " the thrust(trust) is one' own interest"
     regards,
    karthik

    rdgentry1@cablelynx.com (P Gentry) wrote in message news:<facb01db.0402021514.52fae099@posting.google.com>...
    > thegreatkarthik@yahoo.co.in (karthikeyan) wrote in message news:<ecaee7af.0402012316.153a24a8@posting.google.com>...
    >
    > WARNING -- what follows is a best guess effort without the book at
    > hand
    >
    > > sir,
    > > I am handling TCP/IP for Information Technology students.I am having
    > > doubt in retransmission & timeout concepts in TCP connections.
    > > AS per Richards Stevens he suggested in his book that
    > >
    > > " when sending a frame from source the sender will starts its time &
    > > time is calculated in millisecs in network and timer clock which will
    > > start from 0 msec
    > >
    > > 0 msec -----------|------------|-----------|----- so & on
    > > 500 1000 1500 msec
    > > each 500 msec is refered to as one clock tick.
    > > questions :
    > > 1)then how we will calculate timeout because time is increasing in
    > > msecs?
    >
    > timeout is the _elapsed_ time (ie., # of msecs or # of ticks) the
    > sender waits for an acknowledgment -- if none received within
    > _elapsed_ time, the sender will re-transmit
    >
    > > 2)how much amount of time will be considered as timeout?
    >
    > see below RTT and RTO
    >
    > >
    > > question regarding retransmission
    > >
    > > RTT(Round trip time) smooth estimators is calculated by the formula
    > >
    > > RTT optimizer = alpha * previous RTT + (1-alpha) * current RTT (
    > > value of alpha is 0.9)
    >
    > try this:
    > RTT optimizer = (90% of previous RTT) plus (10% of current RTT)
    > current RTT = the last "received (ACK?)" RTT (RTT-0)
    > -- I _think_ it's the acknowledgement (ACK) that marks the end of
    > elapsed time
    > previous RTT = previous to the last "received" RTT (RTT-1)
    > it's a kind of running "average" to _calculate_ the "expected" RTT
    >
    > >
    > > while sending a frame how is it possible to know current RTT
    >
    > read "current" as "most recently" or "last received" -- it obviously
    > can't know the future, so it uses "RTT optimizer" as a smoothed
    > predictor of what is a reasonable expectation under the most recent
    > network conditions
    >
    > > and moreover
    > > RTO(Retransmission TimeOut ) = 2 * RTT optimizer or (2 * RTT
    > > approximately)
    >
    > a rule-of-thumb that works well -- basically it is arbitrary
    >
    > >
    > > my question is retransmission occurs only when there is
    > > some problem (because if the acknowledge is not coming,is it possible
    > > to calculate RTT) then how can i find retransmission.
    >
    > The destination receiver can also "request" a re-transmission by the
    > nature/sequence of its acknowledgements.
    > RTT is _measured_elapsed_ time
    > RTT optimizer is a _calculated_ "expectation" of how long an
    > acknowlegement _should_ take, given recent conditions
    > RTO is the elapsed time without any acknowledgement that triggers a
    > re-transmission (the "it's too quiet" trigger)
    >
    > Transmissions usaully involve sending several segments (1,2,3) in a
    > window before receiving _any_ acknowledgement.
    > This is a window size of one: send 1 ->(ACK 2) then send 2 ->(ACK 3)
    > then send 3 ->(ACK 4). Note the ACK sequence: (got 1 ok, send 2) then
    > (got 2 ok, send 3) then (got 3 ok, send 4).
    > This is a window size of 3: send 1,2,3 ->(ACK 4) then send 4,5,6
    > ->(ACK 7)
    > The receiver could return (ACK 5) or (ACK 6) if it did not recieve
    > those segments properly (the "something is wrong" trigger).
    >
    > Also remember that a TCP "circuit" is _negotiated_ when a connection
    > request is processed -- transmission parameters are part of what is
    > agreed upon before data begins to flow.
    >
    > >
    > > I am searching for book materials but i want to know how timeout
    > > occurs in network and how will calculate that ??
    > > what is relationship between RTT and Retransmission timeout??
    > >
    > > Please help me
    > > Thks in adv..
    >
    > Are you gong to teach this level of detail? Just curious.
    >
    > hth,
    > prg
    > email above disabled

  • Next message: Cameron Kerr: "Re: Pipe closing"