• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Tcp Reliability Flow Control
 

Tcp Reliability Flow Control

on

  • 4,557 views

Unit 4 Of ACN

Unit 4 Of ACN

Statistics

Views

Total Views
4,557
Views on SlideShare
4,550
Embed Views
7

Actions

Likes
0
Downloads
43
Comments
1

1 Embed 7

http://www.slideshare.net 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • good work .....
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Tcp Reliability Flow Control Tcp Reliability Flow Control Presentation Transcript

    • TCP requirements
      • Two key requirements of the protocol:
        • Reliability: Ensuring that data that is sent actually arrives at its destination, and if not, detecting this and re-sending the data.
        • Data Flow Control: Managing the rate at which data is sent so that it does not overwhelm the device that is receiving it.
    • PAR
      • Reliability in communications follow a rule
        • a device to send back an acknowledgment each time it successfully receives a transmission
      • If a transmission is not acknowledged after a period of time, it is retransmitted by its sender
      • This system is called positive acknowledgment with retransmission (PAR)
      • One drawback: the transmitter cannot send next message until the previous is acknowledged.
    • PAR
    • TCP sliding window
      • A variation on the enhanced PAR system
      • To support TCP’s stream orientation
      • Each device keeps track of the status of the byte stream
      • Dividing Data into four conceptual categories:
        • Bytes sent and acknowledged
        • Bytes sent but not yet acknowledged
        • Bytes not yet sent but that can be sent immediately
        • Bytes not yet sent that cannot be sent until the recipient signals that it is ready for them.
    • Data Stream categories
    • Send, usable windows
      • The send window is the key to the entire TCP sliding window system:
        • it represents the maximum number of unacknowledged bytes a device is allowed to have outstanding at once.
      • The usable window is the amount of the send window that the sender is still allowed to send at any point in time;
        • it is equal to the size of the send window less the number of unacknowledged bytes already transmitted.
    • Send and usable window
    • Send and usable window
    • Implementing sliding window
      • Three essential fields in the TCP segment
        • The Sequence Number field indicates the number of the first byte of data being transmitted.
        • The Acknowledgment Number is used to acknowledge data received by the device sending this segment.
        • The Window field tells the recipient of the segment the size to which it should set its send window
    • Window slide
      • When a device gets an acknowledgment for a range of bytes, it knows they have been successfully received by their destination.
      • It moves them from the “sent but unacknowledged” to the “sent and acknowledged” category.
      • This causes the send window to slide to the right, allowing the device to send more data.
    • TCP window size management
      • The receiver on receipt of segment must
        • Send Acknowledgement
        • Transfer data from buffer to application
      • Receiver delay in transfer can happen
      • Danger of buffer overflow
      • Varying window size to manage data flow
    • Flow control
      • The TCP sliding window system is used not just for ensuring reliability through acknowledgments and retransmission
      • it is also the basis for TCP’s flow control mechanism.
      • By increasing or reducing the size of its receive window
        • a device can raise or lower the rate at which its connection partner sends it data.
        • In the case where a device becomes extremely busy, it can even reduce the receive window to zero, closing it
        • this will halt any further transmissions of data until the window is reopened
    • Shrinking window
    • Silly window syndrome
      • Sliding window mechanism does not ensure a min size of segment
      • Shrinking window can result in inefficient transmission of small size segment
    • Silly window syndrome
    • SWS avoidance algorithm
      • Receiver SWS avoidance
        • Restrict moving right edge of window by too small amount
        • Reduce window size to 0
        • Right edge be moved by half buffer size or MSS whichever is less
    • Sender SWS avoidance algorithm
      • Nagle’s algorithm – John Nagle
        • Data can be immediately sent as long as all sent data is acknowledged
        • When there is unacknowledged data
          • Do not send till all data acknowledged
          • Send after accumulating data for full segment
    • TCP ACK & Retransmission
      • TCP acknowledgments are cumulative
      • Tell a transmitter that all the bytes up to the sequence number indicated in the acknowledgment were received successfully.
      • If bytes are received out of order, they cannot be acknowledged until all the preceding bytes are received.
      • TCP includes a method for timing transmissions and retransmitting lost segments if necessary.
    • Managing Retransmissions
      • Each time a segment is sent, a copy is Placed On Retransmission Queue
      • Timer Starts at a predetermined value
      • Counts down over time
      • If an acknowledgment is received for a segment before its timer expires, the segment is removed from the retransmission queue
      • If the timer expires before an acknowledgment is received, the segment is retransmitted
      • No guarantee that a retransmitted segment will be received
      • If not, Retransmission timer is reset, the segment will be retransmitted again and the process repeated
    • Policies For Dealing with Retransmission
      • Retransmit Only Timed-Out Segments
      • Retransmit All Outstanding Segments
      • TCP selective acknowledgment
    • Retransmission Time
      • Length of time for retransmission timer is very important
      • If it is set too low
        • A segment actually received might be retransmitted
        • didn't wait long enough for the acknowledgment
      • if it is set too long
        • waste time waiting for an acknowledgment that will never arrive
        • reducing overall performance
    • Choosing Retransmission time
      • Ideally, the retransmission timer should be of value just slightly larger than the round-trip time (RTT)
      • How to determine RTT?
        • Differences in TCP Connection Distances.
        • Transient Delays and Variability : The amount of time it takes to send data between any two devices will vary over time due to various happenings on the internetwork: fluctuations in traffic, router loads and so on.
    • Adaptive Retransmission Based RTT
      • TCP uses a dynamic, or adaptive retransmission scheme
      • Average RTT value for the connection
      • A smoothing formula:
        • New RTT = (a * Old RTT) + ( (1-a) * Newest RTT Measurement); 0 < a < 1
        • a ~ 1 -> better smoothing, slow reaction
        • a ~ 0 -> fast reaction
    • RTT Calculation by Karn's Algorithm
      • Karn's algorithm- Inventor, Phil Karn
        • Does not use measured round-trip times
        • Eliminates problem of acknowledgment ambiguity
      • Start by setting the timer, based on the current average round-trip time
      • On retransmission, the timer is not reset to the same value but is “backed off” (increased) using a multiplier (typically 2) to give the retransmission more time to be received
      • The timer continues to be increased until a retransmission is successful, up to a certain maximum value
    • RTT Calculation by Karn's Algorithm
      • The round-trip timer is kept at the longer (backed-off) value until a valid round-trip time can be measured on a segment that is sent and acknowledged without retransmission
      • This permits a device to respond with longer timers temporarily, while eventually having the round-trip time settle back to a long-term average when normal conditions resume