• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lecture 5
 

Lecture 5

on

  • 847 views

this is helpfull for all communication field

this is helpfull for all communication field

Statistics

Views

Total Views
847
Views on SlideShare
847
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Lecture 5 Lecture 5 Presentation Transcript

    • Data Communication I Lecture 5 presented by Werner Wild, CEO Evolution Innsbruck, San Francisco, Zurich Contact: info@evolution.at
    • Today’s Lecture Plan
      • TCP
    • TCP
      • Connection oriented byte stream
        • All bytes arrive in order
        • No “boundaries”
      • Not a virtual circuit
        • “ Two end” management
      • Full duplex connection
      • Always point-to-point
    • TCP RFCs: 793, 1122, 1323, 2018, 2581
      • full duplex data:
        • bi-directional data flow in same connection
        • MSS: maximum segment size
      • connection-oriented:
        • handshaking (exchange of control msgs) init’s sender, receiver state before data exchange
      • flow controlled:
        • sender will not overwhelm receiver
      • point-to-point:
        • one sender, one receiver
      • reliable, in-order byte steam:
        • no “message boundaries”
      • pipelined:
        • TCP congestion and flow control set window size
      • send & receive buffers
    • The TCP Header
      • Byte stream sent as sequence of segments
        • Segment may be 0 to 64k bytes
      source port destination port sequence number acknowledgment number window size urgent pointer checksum options data header length unused flags
    • Establishing a Connection
      • Normal connection
      • Host 1 initiates and chooses its initial sequence number.
      • Host 2 replies with its own initial sequence number and acknowledges host 1.
      • Host 1 begins data.
      host 1 host 2 CR (seq=x) ACK (seq=y, ack=x) DATA (seq=x’, ack=y)
    • Duplicate Request (I)
      • A previous connection request appears from nowhere.
      • Host 2 replies with its own initial sequence number and acknowledges host 1.
      • Host 1 rejects the connection request.
      host 1 host 2 CR (seq=x) ACK (seq=y, ack=x) REJECT (ack=y)
    • Duplicate Connection (II)
      • A previous connection request appears from nowhere .
      • Host 2 replies.
      • The first data packet of the previous connection also appears.
      • Host 1 rejects the connection request.
      host 1 host 2 CR (seq=x) ACK (seq=y, ack=x) REJECT (ack=y) DATA (seq=x’, ack=z)
    • Initial Sequence Numbers
      • Ensure no sequence number is reused before all packets and acks have expired.
      • Includes restart after a crash.
      • Large sequence space.
      • Based on bits from a “clock”.
      time sequence numbers initial sequence numbers sequence numbers used forbidden range
    • TCP seq. #’s and ACKs
      • Seq. #’s:
        • byte stream “number” of first byte in segment’s data
      • ACKs:
        • seq # of next byte expected from other side
        • cumulative ACK
      • Q: how receiver handles out-of-order segments
        • A: TCP spec doesn’t say, - up to implementor
      Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘ C’ host ACKs receipt of echoed ‘ C’ host ACKs receipt of ‘ C’, echoes back ‘C’ simple telnet scenario time
    • TCP ACK generation Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap
    • TCP Sequencing
      • Retransmission due to lost acknowledgment.
      • Note sequence number is bytes transmitted.
      A B seq=92, 8 bytes data ack=100 seq=92, 8 bytes data ack=100 timeout
    • TCP Sequencing cont.
      • Cumulative acknowledgment avoids retransmission.
      ack=100 A B seq=92, 8 bytes data seq=100, 20 bytes data ack=120 timeout
    • TCP Sequencing cont.
      • Delayed acknowledgment causes retransmission
      • Subsequent acknowledgment prevents retransmission.
      • Not go-back-n
      • Not selective repeat
      A B seq=92, 8 bytes data seq=92, 8 bytes data ack=100 timeout seq=100, 20 bytes data ack=120 ack=120
    • TCP Flow Control
      • receiver: explicitly informs sender of (dynamically changing) amount of free buffer space
        • RcvWindow field in TCP segment
      • sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow
      sender won’t overrun receiver’s buffers by transmitting too much, too fast receiver buffering RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer flow control
    • Receive Window (Example) application writes 2k sender receiver empty 4k 2k, seq=0 2k ack=2048, win=2048 application writes 3k 2k, seq=2048 4k full ack=4096, win=0 ack=4096, win=2048 2k application reads 2k 1k, seq=4096 2k 1k
    • TCP RTT and Timeout
      • Q: how to set TCP timeout value?
      • longer than RTT
        • note: RTT will vary
      • too short: premature timeout
        • unnecessary retransmissions
      • too long: slow reaction to segment loss
      • Q: how to estimate RTT?
      • SampleRTT : measured time from segment transmission until ACK receipt
        • ignore retransmissions, cumulatively ACKed segments
      • SampleRTT will vary, want estimated RTT “smoother”
        • use several recent measurements, not just current SampleRTT
    • Timeouts
      • What is the appropriate value for a timeout?
      • est_rtt = (1-p)(est_rtt) + p (sample_rtt)
      • dev = (1-p) dev + p |sample_rtt - est_rtt|
    • The End
      • Thank you for your attention !
    • Sources
      • For the preparation of this lectures a lot of sources where used – my special thanks go to :
        • Univ. Auckland
        • Univ. California – San Diego (UCSD)
        • Univ. Hongkong
        • … many others …