INF-3190: Transport Layer - PowerPoint PPT Presentation

Loading...

PPT – INF-3190: Transport Layer PowerPoint presentation | free to download - id: 1f04a7-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

INF-3190: Transport Layer

Description:

Interfaces to IP layer. TCP transport entity on sending side ... IP layer doesn't guarantee that packets will be delivered properly / in order ... – PowerPoint PPT presentation

Number of Views:18
Avg rating:3.0/5.0
Slides: 44
Provided by: plspi
Learn more at: http://folk.uio.no
Category:
Tags: inf | iplayer | layer | transport

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: INF-3190: Transport Layer


1
Transport Layer
  • Foreleser Carsten Griwodz
  • Email griff_at_ifi.uio.no

2
Transport Protocols UDP
3
UDP - User Datagram Protocol
  • Specification
  • RFC 768
  • UDP is a simple transport protocol
  • Unreliable
  • Connectionless
  • Message-oriented
  • gt UDP is mostly IP with short transport header
  • Source and destination port
  • Ports allow for dispatching of messages to
    receiver process
  • Characteristics
  • No flow control
  • Application may transmit as fast as it can / want
    and the network permits
  • No error control or retransmission
  • No guarantee about packet sequencing
  • Packet delivery to receiver not ensured
  • Possibility of duplicated packets
  • May be used with broadcast / multicasting and
    streaming

4
UDP Message Format
  • Source port
  • Optional
  • 16 bit sender identification
  • Response may be sent there
  • Destination port
  • Receiver identification
  • Packet length
  • In byte (including UDP header)
  • Minimum 8 (byte)i.e. header without data
  • Checksum
  • Optional
  • Checksum of header and data for error detection

5
UDP Message Format Checksum
  • Purpose
  • Error detection (header and data)
  • Same algorithm as IP
  • Ones complement of sum of 16-bit halfwords in
    ones complement arithmetic
  • UDP checksum includes
  • UDP header (checksum field initially set to 0)
  • Data
  • Pseudoheader
  • Part of IP header
  • source IP address
  • destination IP address
  • Protocol
  • length of (UDP) data
  • Allows to detect misdelivered UDP messages
  • Use of checksum optional
  • i.e., if checksum contains only "0"s, it is not
    used
  • Transmit 0xFFFF if calculated checksum is 0

6
UDP Ranges of Application
  • Benefits of UDP
  • Needs very few resources (in endsystems, in each
    data unit)
  • No connection establishment (hence, no overhead,
    faster transmission)
  • Simple implementation possible (e.g. suitable for
    boot PROM)
  • Applications can precisely control
  • Packet flow
  • Error handling / reliability
  • Timing
  • Problems of UDP
  • No flow control
  • Packets can be lost because receiving application
    is too slow
  • No congestion control
  • No reaction to network overload

7
UDP Ranges of Application
  • Suitable
  • For simple client-server interactions, i.e.
    typically
  • 1 request packet from client to server
  • 1 response packet from server to client
  • When delay is worse than packet loss and
    duplication
  • Video conferencing
  • IP telephony
  • Gaming
  • Used by e.g.
  • DNS Domain Name Service ¹
  • SNMP Simple Network Management Protocol
  • BOOTP Bootstrap protocol
  • TFTP Trivial File Transfer Protocol
  • NFS Network File System ¹
  • NTP Network Time Protocol ¹
  • RTP Real-time Transport Protocol ¹
  • ¹ can also be used with TCP

8
Transport Protocols TCP
9
TCP - Transmission Control Protocol
  • TCP is the main transport protocol of the
    Internet
  • History
  • RFC 793 originally
  • RFC 1122 and RFC 1323 errors corrected,
    enhancements implemented
  • Motivation network with connectionless service
  • Packets and messages may be
  • duplicated, in wrong order, faulty
  • i.e., with such service only, each application
    would have to provide recovery
  • error detection and correction
  • Network or service can
  • impose packet length
  • define additional requirements to optimize data
    transmission
  • i.e., application would have to be adapted
  • TCP provides
  • Reliable end-to-end byte stream over an
    unreliable internetwork

10
What is TCP?
  • TCP is
  • A transport protocol specification
  • Not a piece of software
  • TCP specifies
  • Data and control information formats
  • Procedures for
  • flow control
  • error detection and correction
  • connect and disconnect
  • As a primary abstraction
  • a connection
  • not just the relationships of ports (as a queue,
    like UDP)
  • TCP does not specify
  • The interface to the application (sockets,
    streams)
  • Interfaces are specified separately e.g.
    Berkeley Socket API, WINSOCK

11
TCP in Use Application Areas
  • Each machine supporting TCP has a TCP transport
    entity
  • Library procedure
  • User process
  • Part of kernel
  • TCP transport entity manages
  • TCP streams
  • Interfaces to IP layer
  • TCP transport entity on sending side
  • Accepts user data streams for local processes
  • Splits them into pieces lt 64 KB
  • Often 1460 bytes
  • (to fit into single Ethernet frame with IP and
    TCP headers)
  • Sends each piece as separate IP datagram
  • TCP transport entity on receiving side
  • Gets TCP data from packets received at host
  • Reconstructs original byte streams
  • TCP must ensure reliability
  • IP layer doesnt guarantee that packets will be
    delivered properly / in order (TCP must handle
    this, e.g. timeout and retransmit / reorder)

12
TCP in Use Application Areas
  • Benefits of TCP
  • Reliable data transmission
  • Efficient data transmission despite complexity
  • (up to 8Mbps on 10Mbps ethernet)
  • Can be used with LAN and WAN for
  • low data rates (e.g. interactive terminal) and
  • high data rates (e.g. file transfer)
  • Disadvantages when compared with UDP
  • Higher resource requirements
  • buffering, status information, timer usage
  • Connection set-up and disconnect necessary
  • even with short data transmissions
  • Applications
  • File transfer (FTP)
  • Interactive terminal (Telnet)
  • E-mail (SMTP)
  • X-Windows

13
TCP Characteristics
  • Data stream oriented
  • TCP transfers serial byte stream
  • Maintains sequential order
  • Unstructured byte stream
  • Application often has to transmit more structured
    data
  • TCP does not support such groupings into (higher)
    structures within byte stream
  • Buffered data transmission
  • Byte stream not message stream message
    boundaries are not preserved
  • no way for receiver to detect the unit(s) in
    which data were written
  • For transmission the sequential data stream is
  • Divided into segments
  • Delayed if necessary (to collect data)
  • For more efficient transmission (e.g. network
    utilization)

14
TCP Characteristics
  • Virtual connection
  • Connection established between communication
    parties before data transmission
  • Two-way communications (fully duplex)
  • Data may be transmitted simultaneously in both
    directions over a TCP connection
  • Point-to-point
  • Each connection has exactly two endpoints
  • Reliable
  • Fully ordered, fully reliable
  • Sequence maintained
  • No data loss, no duplicates, no modified data

15
TCP Characteristics
  • Error detection
  • Through checksum
  • Piggybacking
  • Control information and data can be transmitted
    within the same segment
  • Out-of-band data expedited data
  • Important information sent to receiver
  • i.e. should get to receivers application before
    data that was sent earlier
  • PUSH operation
  • Data is not stored in a buffer
  • Sent immediately and immediately made available
    to application on receivers end
  • example ltCRgt end of line at terminal emulation
  • Urgent flag
  • Send and transfer data to application immediately
  • example ltCrtl Cgtarrival interrupts receivers
    application

16
TCP Characteristics
  • No broadcast
  • No possibility to address all applications
  • With connect, however, not necessarily sensible
  • No multicasting
  • Group addressing not possible
  • No QoS parameters
  • Not suited for different media characteristics
  • No real-time support
  • No correct treatment / communications of audio or
    video possible
  • E.g. no forward error correction

17
Connection Addressing
Connection
Process
Process
Port
Port
Port
  • Passive open
  • Process indicates that it would accept connect
    request
  • Active open
  • Process requests a connection
  • Addressing
  • Port number protocol identification
  • clearly identifies entity in the ES
  • IP address
  • clearly identifies ES

18
Connection Addressing
  • TCP service obtained via service endpoints on
    sender and receiver
  • Typically socket
  • Socket number consists of
  • IP address of host and
  • 16-bit local number (port)
  • Transport Service Access Point
  • Port
  • TCP connection is clearly definedby a quintuple
    consisting of
  • IP address of sender and receiver
  • Port address of sender and receiver
  • TCP protocol identifier
  • Applications can use the same localports for
    several connections

Server offers (IP addr/port/TCPid) (1.1.1.1/1/6)
(2.2.2.2/2/1.1.1.1/1/6)
1.1.1.1
2.2.2.2
2
1
3
(2.2.2.2/3/1.1.1.1/1/6)
4
(IP addr sender/port sender/ IP addr recv/port
recv/TCPid) (3.3.3.3/4/1.1.1.1/1/6)
3.3.3.3
19
Connection Establishment
  • One passive one active side
  • Server wait for incoming connection using LISTEN
    and ACCEPT
  • Client CONNECT (specifying IP addr. and port,
    max. TCP segment size)
  • Three-Way-Handshake
  • Connecting through 3 packets
  • Comments
  • When establishing a connection
  • initial sequence numbers of both partners are
    also exchanged and acknowledged
  • initial seq. is not 0
  • SYN segment consumes one byte of sequence space
  • in order to be acknowledged unambiguously

Host 1 Client
Host 2 Server
send SYN(SEQx)
receive SYN
send SYN(SEQy) ACK(SEQx1)
receive SYNACK
send SYN(SEQx1) ACK(SEQy1)
receive SYNACK
time
time
20
Connection Establishment
  • Comments
  • If on server side no process is waiting on port
    (no process did LISTEN)
  • Reply segment with RST bit set is sent to reject
    connection attempt
  • Process listening on port may accept or reject

Host 1 Client
Host 2 No server
send SYN(SEQx)
receive SYN
send RST
time
time
21
Connection Establishment
  • Call collision
  • Still only one single connection will be
    established even when
  • both partners actively try to establish a
    connection simultaneously

Host 1 Client Server
Host 2 Client Server
send SYN(SEQx)
send SYN(SEQy)
receive SYN
receive SYN
send SYN(SEQy) ACK(SEQx1)
send SYN(SEQx) ACK(SEQy1)
receive SYNACK
receive SYNACK
time
time
22
Connection Release
  • Connection release for pairs of simplex
    connections
  • each direction is released independently of other
  • Connection release by either side sending a
    segment with FIN bit set
  • no more data to be transmitted
  • when FIN is acknowledged, this direction is shut
    down for new data
  • Directions are released independently
  • other direction may still be open
  • full release of connection if both directions
    have been shut down

23
Connection Release
  • Systematic disconnect by 4 segments
  • between 2nd and 3rd
  • host 2 can still send data to host 1
  • Reduction of packet number possible
  • first ACK and second FIN may be contained in same
    segment(3 segments instead of 4)
  • Connection interrupt Opposite side cannot
    transmit data anymore
  • immediate acknowledgement, release of all
    resources
  • data in transit may be lost

Host 1 Peer
Host 2 Peer
send FIN(seqx)
receive FIN
send ACK(SEQx1)
receive ACK
send FIN(SEQy) ACK(SEQx1)
receive ACKFIN
send ACK(SEQy1)
receive ACK
time
time
24
Connection Management Modelling
  • States

State Description
CLOSED No connection is active or pending
LISTEN Server is waiting for an incoming call
SYN RCVD Connection request has arrived, wait for ACK
SYN SENT Application has started to open a connection
ESTABLISHED Normal data transfer state
FIN WAIT 1 Application has said it is finished
FIN WAIT 2 The other side has agreed to release
TIMED WAIT Wait for all packets to die off
CLOSING Both sides have tried to close simultaneously
CLOSE WAIT The other side has initiated a release
LAST ACK Wait for all packets to die off
25
States
Timeout
Send SYN
Recv SYN Send SYN ACK
Recv RST
Send SYN
Recv SYN Send SYN ACK
Recv SYN ACK Send ACK
Recv ACK
Send FIN
Recv FIN Send ACK
Send FIN
Send FIN
Recv FIN Send ACK
Recv FIN ACK Send ACK
Recv ACK
Recv ACK
Timeout
Recv FIN Send ACK
26
Typical State Sequenceof a TCP Client
CLOSED
LISTEN
SYN RCVD
SYN SENT
ESTABLISHED
CLOSE WAIT
LAST ACK
FIN WAIT 1
CLOSING
FIN WAIT 2
TIME WAIT
27
Typical State Sequenceof a TCP Server
CLOSED
Timeout
LISTEN
SYN RCVD
SYN SENT
ESTABLISHED
CLOSE WAIT
LAST ACK
FIN WAIT 1
CLOSING
FIN WAIT 2
TIME WAIT
28
TCP Packets and Fragments
29
TCP - Protocol, PDU Format, Segments
  • TCP/IP Header Format

Version
IHL
Type of service
Total length
PRE
ToS
Identification
D
M
Fragment offset
Time to live
Protocol
Header checksum
IP header
Source address
Destination Address
Options
Source port
Destination port
Sequence number
Piggyback acknowledgement
TCP header
THL
F
Window
S
R
P
A
U
unused
Checksum
Urgent pointer
Options (0 or more 32 bit words)
THL TCP header length U URG urgent A ACK
acknowledgement P PSH push R RST reset S
SYN sync F FIN finalize
30
Segments
  • TCP entitites exchange data in form of segments
  • TCP segment consists of
  • Fixed 20 byte header (plus optional part)
  • Zero or more data bytes
  • TCP software (entity) decides
  • Segment size to be used
  • Data from several writes can be accumulated into
    one segmentor
  • Data from one write can be split into several
    segments
  • Limits
  • Each segment (including TCP header) must fit into
    65515 byte IP payload
  • Segment must fit into maximum transfer unit (MTU)
    of visited networks
  • Each network may have MTU, depending on L2
    technology used
  • Often 1500 byte (Ethernet payload size), typical
    upper bound on segm. Size
  • Further on (if really needed) IP will "fragment"
    packetsif they are too large for visited networks

31
Identification of TCP-Packets i.e. Segments
  • A key feature
  • Every byte on TCP connection has its own 32-bit
    sequence number
  • Separate sequence numbers used for
  • Data
  • Acknowledgements
  • Window mechanism
  • Remember
  • 32-bit sequence number space was big in early
    days of the Internet
  • Nowadays, it can be consumed very fast

32
Protocol with Flow Control
  • TCP uses Sliding window protocol
  • Sender starts timer when it transmits segment
  • Receiving TCP entity sends back a segment
  • With data if any, otherwise without data
  • Acknowledgment number equal to next sequence
    number it expects to receive
  • If senders timer goes off before acknowledgement
    arrives
  • Segment is retransmitted
  • Secondary interpretation for congestion control

33
Segments, Fragmentation (and Reassembly)
  • Fragments
  • IP packets are split (if necessary) into
    fragments in order to adapt them to underlying
    networks
  • IP does not reassemble
  • Segments
  • TCP Data stream split into segments
  • Segments sent as IP packets
  • TCP reassembles segments and fragments

34
Segments, Fragmentation (and Reassembly)
ID 43
MF 0
FA 0
TCP header data (250 byte)
ID 43
MF 1
FA 0
104 byte
IP header 20 byte
ID 43
MF 1
FA 13
104 byte
ID Datagram Identification MF More Fragments
bit 0 no 1 yes FA Fragment Offset
n n8 byte
IP header 20 byte
ID 43
MF 0
FA 26
42 byte
IP header 20 byte
35
TCPReliability and Ordering
  • Timers

36
Timer Management
Ideal situation
  • TCP uses several timers for different purposes
  • Retransmission timer as most important one
  • Timer is set when segment is sent
  • If ACK arrives before timer expires timer is
    stopped
  • If timer expires before ACK arrives segment is
    retransmitted
  • and new timer is set
  • Question How long should the timeout interval be?

Time out
Probability
Round trip time (msec)
Closer to real situation
Time out
too short
too long
Probability
Round trip time (msec)
37
Timer Management
  • Timeout after a certain time period
  • Situation in the Internet packet communication
    time may vary immensely
  • Timeout too short
  • fast reaction due to any errors
  • but correct packets retransmitted
  • Timeout too long
  • too slow reaction due to errors
  • less additional traffic
  • Better adaptive timeout intervals
  • Timeout period (until retransmit)
  • continuous adaptation to pre-calculated, expected
    waiting period
  • Waiting period increases for each retransmission
    of the same segment

38
Timer Management
  • Relevant parameters
  • RTT Round Trip Time (or Round Trip Sample)
  • time between
  • sending of octet and the receiving of respective
    acknowledgment
  • Timeout initiates retransmission
  • Algorithm (Jacobson, 1988)
  • a Smoothing factor
  • 0..1 determines importance of the history
  • 0 only current/last value is relevant
  • 7/8 typical Value
  • 1 only old values are relevant
  • b (later/today proportional to the average
    deviation)
  • 1 faster error correction
  • 2 original value in implementations
  • Comment usually hard to define (as fixed value)

39
RTT Calculation in Case of Error Recovery
  • How to handle dynamic RTT estimation when segment
    must be resent?
  • Situation ambiguous measurement
  • t1 retransmit initiated because of timeout
  • t2 acknowledgement arrives at the receivers
  • Question
  • Does confirmation refer to
  • 1. data which has previously been thought as
    being lost?or
  • 2. data which has been sent last?
  • Problem no differentiation possible
  • This influences the definition/parameter setting
    of the timeout
  • By the RTT measured

40
RTT Calculation in Case of Error Recovery
  • Situation ambiguous measuring
  • 1st assumption
  • Reference to the data sent first (originally)
  • But situation is following
  • Short-term increase in the delay
  • For any unknown reason
  • But not really any loss of data
  • Acknowledgement arrives shortly after timeout
  • Result
  • New-Round_Trip_Sample has very high values
  • RTT increases
  • Sender
  • Now, if sender detects (at later time) packets
    that have been lost
  • Retransmits at a (very) later point in time
  • Consequently acknowledgements are also returned
    later
  • Global effect
  • RTT may increase even more and more

41
RTT Calculation in Case of Error Recovery
  • Situation ambiguous measuring
  • 2nd assumption
  • Reference to last retransmitted data
  • But situation occurred due to
  • Internet in fact losses data
  • Result
  • New_Round_Trip_Sample has smaller value
  • RTT is reduced
  • Sender
  • May set time interval which may be too short
  • The acknowledgement of the first packages will
    again further reduce RTT
  • Global effect
  • RTT gets too small
  • Usually at 1/2 of the actual value
  • i.e. on the average each segment will be sent
    twice

42
RTT Calculation in Case of Error Recovery
  • Fix Karns algorithm
  • Ignore the measurements of lost packets
  • But this would not reflect actual system changes
    in a correct manner
  • Previous algorithm
  • Timer backoff strategy
  • Increase timeout for each lost packet (actually
    each segment) until a segment has arrived
  • g-value typically 2
  • Comment
  • By Phil Karn
  • Karn used TCP based on (very unreliable) radio
    transmission

43
RTT Calculation in Case of Error Recovery
  • Further improvements
  • Karns algorithm
  • Bad adjustment whenever
  • Variation of consecutive delays is large
  • e.g. short-long-short-long ...
  • High load means
  • Often large fluctuations within the delays
  • Larger standard deviation (as well as average
    runtime deviation)
  • Therefore deviation to be used (instead of b)
  • Previously
  • New algorithm

44
TCPReliability and Ordering
  • Duplicates

45
Duplicates (in Data Transfer Phase)
  • Initial Situation Problem
  • Network has
  • Varying transit times for packets
  • Certain loss rate
  • Storage capabilities
  • Packets can be
  • Manipulated
  • Duplicated
  • Resent by the original system after timeout
  • In the following, uniform term "Duplicate
  • A duplicate originates due to one of the above
    mentioned reasons and
  • Is at a later (undesired) point in time passed to
    the receiver

Customer
Bank
Money transfer
CR
DUP
Money transfer is repeated
DATA
DUP
REL
DUP
time
time
46
Example Duplicates
  • E.g. description of possible error causes and
    their possible consequences (5 transactions)
  • Due to network capabilities
  • Duplication of senders packets
  • Subsequent to the first 5 packets duplicates are
    transferred in correct order to the receiver
  • Also conceivable is that an old delayed DATA
    packet (with faulty contents) from a previous
    session may appear this packet might be
    processed instead of or even in addition to the
    correct packet
  • Result
  • Without additional means thereceiver cannot
    differentiatebetween correct data and
    duplicateddata
  • Would re-execute the transaction

47
Duplicates - Description of Problematic Issues
  • 3 somehow disjoint problems
  • How to handle duplicates within a Connection?
  • What characteristics have to be taken into
    account regarding
  • Consecutive connections or
  • Connections which are being re-established after
    a crash?
  • What can be done to ensure that a connection that
    has been established
  • Has actually been initiated by and
  • With the Knowledge of both Communicating parties?
  • See also the lower part of the previous
    illustration

48
Duplicates - Methods of Resolution
  • Using temporary valid TSAPs
  • Method
  • TSAP valid for one connection only
  • generate always new TSAP
  • Evaluation
  • in general not always applicable process server
    addressing method not possible, because
  • server is reached via a designated TSAP
  • some TSAPs always exist as "well known
  • Identify connections individually
  • Method
  • each individual connection is assigned a new
    SeqNo and
  • endsystems remember already assigned SeqNo
  • Evaluation
  • endsystems must be capable of storing this
    information
  • Prerequisite
  • connection oriented system (what if
    connection-less?)
  • endsystems, however, will be switched off and it
    is necessary that the information is reliably
    available whenever needed

49
Duplicates - Methods of Resolution
  • Identify PDUs individuallyindividual sequential
    numbers for each PDUs
  • Method
  • SeqNo basically never gets reset
  • e.g. 48 bit at 1000 msg/sec reiteration after
    8000 years
  • Evaluation
  • higher usage of bandwidth and memory
  • sensible choice of the sequential number range
    depends on
  • the packet rate
  • a packets probable "lifetime" within the network
  • discussed in more detail in the following

50
Duplicates Approach to Limit Packet Lifetime
  • Enabling the above Method 3Identify PDUs
    individually individual sequential numbers for
    each PDUs
  • SeqNo only reissued if
  • all PDUs with this SeqNoor references to this
    SeqNo are extinct
  • i.e., ACK (N-ACK) have to be included
  • otherwise new PDU may be wrongfully confirmed or
    non-confirmed by delayed ACK (N-ACK)
  • Mandatory prerequisite for this solution
  • limited packet lifetime
  • i.e. introduction of a respective parameter T

51
Duplicates Approach to Limit Packet Lifetime
  • Limitation by appropriate network design
  • inhibit loops
  • limitation of delays in subsystems adjacent
    systems
  • Hop-counter / time-to-live in each packet
  • counts traversed systems
  • if counter exceeds maximum value gt packet is
    discarded
  • Time marker in each packet
  • packet exceeds maximum configurable lifetime
  • gt packet is discarded
  • notice requires "consistent" network time

52
Duplicates Approach to Limit Packet Lifetime
  • Determining maximum time T, which a packet may
    remain in the network
  • T is a small multiple of the (real maximal)
    packet lifetime t
  • T time units after sending a packet
  • the packet itself is no longer valid
  • all of its (N)ACKs are no longer valid
  • TCP/IP term Maximum Segment Lifetime (MSL)
  • to be imposed by IP layer
  • defined by and referenced by other protocol
    specifications
  • 2 minutes

53
TCPReliability and Ordering
  • Initial sequence number allocation

54
Handling of Consecutive Connections
  • Problem (wrt. "Identify PDUs individually
    individual sequential numbers for each PDU")
  • to be consideredpackets from connections which
    can otherwise not be distinguished
  • hence at TCP that is
  • same source and destination address and same
    source and destination port
  • this is always unique at one point in time
  • using consecutive sequential numbersfrom
    sufficiently large sequential number range
  • resolves problems with duplicates within a single
    connection
  • duplicates are all other packets with the same
    sequential number
  • irrelevant is origin of packets, sequence of
    creation
  • Problems
  • restart after crash
  • (very fast) reconnect between exactly the same
    communication entities
  • (addr./port see above), information about
    previous connections do not exist anymore after
    crash/restart, generally all conn. have to be
    reconsidered
  • complete usage of the range of available
    sequential numbers

55
Handling of Consecutive Connections
  • Method
  • Endsystems
  • Timer continues to run at switch-off / system
    crash
  • Allocation of initial SeqNo (ISN) depends on
  • Time markers (linear or stepwise curve because of
    discrete time)
  • SeqNos can be allocated consecutively within a
    connection
  • Curve consisting out of discrete points may have
    any gradient form depending on the method used
    for sending the data

Wraparound (e.g. after 4,55h)
e.g. 232-1
T
ISN
ISN
SeqNo
time
ISN Initial Sequence Number
Forbidden Region Width T (max. theoretic packet
lifetime)
56
Handling of Consecutive Connections
  • No problem, if
  • Normal lived session (shorter than wrap-around
    time) with data rate smaller than ISN rate
    (ascending curve less steep)
  • Then, after crash
  • Reliable continuation of work always ensured
  • System clock may be used to continue with correct
    ISN

57
Handling of Consecutive Connections
  • Problems possible, if
  • SeqNo is used within time period T before it is
    being used as initial SeqNo
  • gtForbidden Region" - begins T before Initial
    SeqNo (ISN) is generated
  • i.e. endsystem has to check if the PDU is in the
    forbidden region before it is sent (during the
    actual data phase), (enters from left)
  • Long lived" session (longer than wrap-around
    time)
  • High data rate
  • curve of the consecutively allocated sequence
    numbers steeper than ISN curve (enters from
    underneath)

58
Handling of Consecutive Connections
  • Note
  • 32 bit sequence numbers with technology
    considered as sufficient when designing TCP/IP
  • Sequence number range exploitation
  • today at 1 Gbps
  • in 17 sec
  • gt Using timestamps in
  • "TCP extensions for highspeed paths
  • PAWS "Protect Against Wrapped Sequence Numbers
  • Further literature in addition to Tanenbaum
  • RFC 793 (TCP) / Sequence Numbers "When to keep
    quiet
  • RFC 1185 / Appendix - Protection against Old
    Duplicates
  • RFC 1323 / PAWS
  • Protect Against Wrapped Sequence Numbers
  • Appendix B - Duplicates from Earlier Connection
    Incarnations
About PowerShow.com