TCPIP Transport Layer Protocols: UDP and TCP

1
TCP/IP Transport Layer ProtocolsUDP and TCP

• 635.413.31 Summer 2007

2
The need for a Transport Layer

• It is possible to interface an application
  directly to the IP Layer, but IP does not provide
  much of the functionality an application needs
• Higher-layer addressing
• Error detection
• Reliability
• What the Transport Layer does
• Accept data from the application process, split
  it up into chunks if necessary, send it to the
  network layer, and ensure that the pieces all
  arrive correctly and are delivered to the peer
  application process.
• Provides end-to-end delivery
• May provide different types of service

3
The User Datagram Protocol (UDP)

• Why have UDP?
• IP only provides delivery to the destination host
  (NIC)
• IP also has little end-to-end functionality
• Most hosts need to be able to run multiple
  simultaneous processes that require networked
  communication
• What UDP Provides?
• Unreliable connectionless protocol with low
  overhead
• Requires less processor utilization on hosts and
  routers
• With some data types reliability and
  retransmission is not required or wanted
• With some applications the functionality TCP
  provides may be redundant
• One of the earliest Internet standards defined
  in RFC 768

4
Examination of the UDP header

• Header is fixed length eight bytes long
• Source Destination Port Numbers
• A port is an abstraction or representation of an
  application process that communicates across an
  internet
• Application process identifiers tend to be very
  dynamic
• Would like to allow process IDs to change without
  having to inform all potential senders
• Want to have an identifier that identifies a
  function and not a process
• Well known port numbers defined in RFC 1700
  typically the same for services that can use both
  TCP and UDP though that is not required.

5
Examination of the UDP header

• Length field
• Includes both header and data maximum payload of
  65507 bytes
• Redundant because header size is fixed its
  easy to tell the UDP datagram length from the IP
  packet length
• The Host Requirements RFC does not require an
  Internet connected host to accept a UDP packet
  larger than 568 bytes
• UDP checksum field
• Checksum verifies UDP header and data as well as
  certain portions of the IP header (IP addresses,
  IP protocol field, and IP packet length) called
  the pseudoheader
• Included to make sure the UDP datagram did not
  end up at the wrong destination
• This checksum is end-to-end between transport
  layer applications
• Datagrams with errors are silently discarded
• The sender has the option of disabling the UDP
  checksum (sending all zeros in the checksum
  field) this is not recommended!

6
The Transmission Control Protocol (TCP)

• Introduction
• TCP was developed to provide reliable stream
  transport service, a fundamental enhancement to
  the unreliable packet delivery service IP
  provides
• TCP has been so important and successful that the
  protocol has been adapted to run across other
  networking and internetworking technologies
• TCP is one of the earliest standard Internet
  protocols defined in RFC 793 and extended and
  amended by many subsequent RFCs (in particular
  the Host Requirements RFCs 1122 and 1123)

7
TCP Background Information

• The Need for Reliable Stream Transport
• Unreliable network delivery is a fact of life in
  IP-based networks
• Lost or corrupt packets
• Delayed packets
• Duplicated packets
• Out-of-order delivery of packets
• At the highest layer, many applications require
  reliable delivery of data between users
• If the network does not provide reliable service,
  the application must encompass this functionality
• Makes application development more complex and
  costly
• Causes a proliferation of proprietary transport
  mechanisms built into applications

8
TCP Background Information

• The Five Properties of Reliable Stream Delivery
  Service
• Stream Orientation the destination application
  receives the same stream of bytes that the source
  application sent
• Virtual Circuit Connections connections must be
  set up and torn down after use applications
  think they have a dedicated communication circuit
• Buffered Transfer although data is delivered in
  order to the destination application, it is
  divided up in the most efficient manner for
  transport
• A Push mechanism is defined to distinguish
  important data that must not be buffered but
  does not respect record boundaries
• Unstructured Streams application layer
  structure or boundaries are not recognized or
  respected by the transport layer the
  applications must agree on stream structure and
  syntax
• Full-duplex Connections connections are
  bi-directional to minimally allow
  acknowledgements piggybacking of
  acknowledgements is a key efficiency feature

9
TCP Background Information

• Providing Reliability
• A key question at the transport layer is how to
  provide reliable stream service over an
  unreliable network
• There are different ways to accomplish this, but
  the most proven technique used in a majority of
  working implementations is called
• Positive Acknowledgement with Retransmission
• Features of Positive Acknowledgement with
  Retransmission
• Requires full-duplex communication and the
  destinations ability to acknowledge data
• Sender must keep a copy of the data until it is
  acknowledged
• Timer used to control retransmission to ensure
  delivery if a packet is lost or delayed
• Sequence numbers required to protect against
  duplicate packets
• Figures 12.1/12.2 -- examples of PAR at work

10
TCP Background Information

• The Idea behind Sliding Windows
• A simple Positive Acknowledgement with
  Retransmission scheme makes very inefficient use
  of network resources
• Adding the sliding window mechanism allows
  multiple data segments to be transmitted
  simultaneously before receiving the first
  acknowledgement
• The window is the mechanism that controls how
  much unacknowledged data can be in transit
• The sender must buffer a copy of each outstanding
  data segment until it is acknowledged
• There are two sub-varieties of the sliding window
  mechanism -- go-back-N and selective
  acknowledgements
• Examples of Sliding Windows in Operation (Figures
  12.3 12.4)
• The key is that a well-tuned sliding window
  mechanism keeps the network completely saturated
  with data segments
• A key factor in how well this can be accomplished
  is the bandwidth-delay product of the path from
  source to destination

11
The Transmission Control Protocol (TCP)

• Key Concept TCP is a communications protocol,
  not a piece of software
• What the TCP standards address
• Format of data segments and acknowledgements for
  reliable data transfer
• Addressing of data between endpoints
• What to do when errors occur
• Initiating ending data transfers
• TCP does not define the application layer
  interface to allow for flexibility in
  implementations, though these have become pretty
  well standardized
• There are a variety of TCP implementations, all
  with slight variances
• Some of these are because there are many
  suggestions (SHOULD) in the standard while only
  fundamental features are required
• Examples of variations are with timer values and
  the use of Keepalive segments

12
The Transmission Control Protocol (TCP)

• Ports, Connections, and Endpoints
• While TCP uses ports (like UDP), it is meant for
  more complex operations where an application
  process provides services to multiple concurrent
  users
• TCP and UDP port numbers are independent (because
  of the Protocol field in the IP header), though
  many services that use both protocols use the
  same number for human convenience (e.g. - DNS)
• A connection is the fundamental abstraction used
  by TCP
• A connection is uniquely identified by a pair of
  endpoints
• An endpoint consists of a pair of integers (IP
  address, TCP port)
• Because TCP uses connections identified by a pair
  of endpoints, a given TCP port can be shared by
  multiple connections on a host
• Example email or web access to a server

13
The Transmission Control Protocol (TCP)

• Passive Active Opens
• Unlike UDP, TCP is a connection-oriented protocol
  that requires both endpoints to agree to
  participate in the connection
• At minimum, an endpoint must perform a passive
  open
• This signals an application processes desire to
  accept incoming TCP connections
• Application processes usually signal the
  operating system to assign a TCP port number to
  the process and begin listening for connections
• An endpoint that wishes to open a TCP connection
  to another endpoint must perform an active open
• The application process signals the operating
  system to open a connection to a specific
  endpoint
• Once a connection is open, data can be sent and
  received (more details later)

14
The Transmission Control Protocol (TCP)

• Segments, Streams, Sequence Numbers
• To provide efficient data transmission, TCP takes
  the data stream from the application layer and
  divides it into segments for transmission
• One segment Payload of one transmitted IP
  datagram
• TCP uses a special sliding window mechanism in
  data transmission for two reasons transmission
  efficiency and end-to-end flow control
• Window and sequence numbers are based on byte
  count, not segments
• Connections are full-duplex, so two pairs of
  sliding windows (a total of four) are associated
  with each connection
• Three pointers are necessary for the management
  of each of the four windows (Figure 12.6)

15
The Transmission Control Protocol (TCP)

• Variable Window Size Flow Control
• A key difference between TCP simpler sliding
  window implementations
• To provide flow control, TCP uses a variable size
  sliding window
• The receiver, though the use of a window
  advertisement in every Acknowledgement, changes
  the size of the transmitters send window
• The window can be increased or decreased, though
  the window cannot be decreased past previously
  acceptable positions in the data stream
• To completely cut off the flow, the receiver can
  advertise a zero window
• Sender can occasionally transmit a window probe
  to confirm that the receivers window is still
  closed (this prevents a deadlock condition)
• Sender can also transmit a segment with the
  Urgent bit set
• Note that this is end-to-end flow control
  intermediate nodes can become congested and
  affect connection throughput
• TCP has no explicit mechanisms for dealing with
  congestion
• There are several implicit mechanisms for dealing
  with congestion discussed later

16
The Transmission Control Protocol (TCP)

• TCP Segment Format

17
The Transmission Control Protocol (TCP)

• TCP Segment Format
• Consists of two main parts header and payload
• Header typically 20 bytes long though options are
  allowed that can increase its size to a maximum
  of 60 bytes
• Standard TCP Header Fields
• Source Destination Port Numbers
• Port numbers are 16 bits long and serve as the
  Transport layer addresses
• Well Known Ports defined in RFC 1700 correspond
  to common services (some are listed in Figure
  12.16)
• Reserved Ports Considered a UNIX term for
  ports under 1024 (Usually owned by root and
  therefore the processes had special privileges)
• Ephemeral Ports high numbered ports that are
  dynamically assigned used by clients to connect
  with servers

18
The Transmission Control Protocol (TCP)

• Standard TCP Header Fields (continued)
• Sequence number field
• 32 bit field uniquely identifies the segment
  being sent
• field increments for each segment, eventually
  wrapping around to zero
• Acknowledgement number field (piggybacking)
• 32 bit field specifying the sequence number of
  the last TCP segment that was successfully
  received at the destination (actually the next
  byte expected)
• TCP is a sliding window protocol with positive
  but no negative acknowledgements
• Header Length field
• Four bit field counts the number of four bytes
  words in the TCP header
• Minimum header length is 20 bytes, maximum is 60
  bytes

19
The Transmission Control Protocol (TCP)

• Standard TCP Header Fields (continued)
• TCP Flags (very important!)
• SYN bit set denotes the sender wants to
  initiate a TCP session (SYNCHRONIZE sequence
  numbers)
• FIN bit set denotes the sender wants to
  terminate a TCP session
• URG bit set denotes the URGENT pointer is valid
  and there is at least some Urgent data in the TCP
  segment
• PSH bit set denotes segment contains data that
  should be passed to the receiving application as
  soon as possible
• RST bit set causes an existing TCP connection
  to be RESET (connection closed abruptly with all
  data in buffers thrown out)
• Also used when a host receives a TCP Connection
  Request and no TCP process is listening on that
  particular port number
• ACK bit set denotes the ACKNOWLEDGEMENT field
  is valid (segments up to the number in that field
  are acknowledged)

20
The Transmission Control Protocol (TCP)

• Standard TCP Header Fields
• Window size field
• Provides the flow control in TCP counts in bytes
  (not segments)
• Window shows the number of bytes the destination
  host is willing to receive a any given moment
• Window has a maximum size of 65535 bytes (without
  using the window scale option)
• TCP checksum field
• Checks the TCP header and payload as well as
  additional IP header fields (same as the UDP
  checksum)
• Error detection only if an error is detected the
  segment is discarded and must be retransmitted
• This is a very simple scheme there are
  combinations of bit errors that can fool the
  checksum and pass undetected

21
The Transmission Control Protocol (TCP)

• Standard TCP Header Fields
• Urgent Pointer field
• Used in conjunction with URG bit to denote and
  located any urgent data in the TCP segment
• Urgent data is typically data that the sending
  application deems important enough that it should
  receive attention ahead of any previously
  received data present in the destinations
  buffers
• Urgent data may be priority data, but most of the
  time it is used to send abort or interrupt
  sequences
• Urgent pointer is a positive offset that must be
  added to the Sequence number field to yield the
  end of the urgent data
• Implementation of Urgent mode is system dependent!

22
The Transmission Control Protocol (TCP)

• TCP Segment Options Maximum Segment Size (MSS)
• Not all TCP segments sent across a connection
  will be the same size, but both ends must agree
  on the maximum allowable segment size
• MSS should be chosen based on two criteria
• Efficient use of the network (segments too small
  have an overhead penalty, segments too large
  cause fragmentation)
• Allocated buffer space other considerations at
  the destination
• The best MSS sends segments as large as possible
  without causing fragmentation
• Internet dynamics make determining the optimal
  MSS very difficult
• Some implementations have a process called Path
  MTU Discovery to help determine the optimum MSS
• ICMP messages are sent to the destination with
  the Do Not Fragment Flag set starting with a
  guess at a good MSS
• If ICMP Fragmentation Required error messages
  keep returning reduce MSS until no errors are
  returned use that size for MSS

23
The Transmission Control Protocol (TCP)

• TCP Segment Options Window Scale Option
• New option defined in RFC 1323 -- TCP Extensions
  for High Performance
• Allows a window size greater than 65,535 bytes to
  be negotiated by defining a window scale
  multiplier to be exchanged that increases the
  window size to a 230-1 bytes
• Transmitted as a 3 byte option with three fields
  (Option type, Option length, and multiplier) in
  TLV format
• Negotiated at the beginning of a TCP connection
  can only work if both sides support this option
• Each direction of the connection can use a
  different multiplier
• The maximum window multiplier is 14
• Does not affect how TCP flow and congestion
  control mechanisms work!

24
The Transmission Control Protocol (TCP)

• More on Acknowledgements Retransmission
• TCP uses cumulative acknowledgements in other
  words a TCP acknowledgement specifies the
  sequence number of the next byte it expects to
  receive
• Advantages
• Easy and efficient to generate
• Provides protection against lost acknowledgements
• Disadvantages
• Sender does not receive notification of all
  successfully received segments, just the last
  cumulative byte successfully received
• Can cause sliding widow based protocols to become
  inefficient when handling retransmissions -- must
  choose one of two scenarios
• Retransmit all data in transmit window
• Must guess at what data was lost and only
  retransmit those segments

25
The Transmission Control Protocol (TCP)

• Timeout and Retransmission
• One of the most significant and complex areas in
  TCP concerns how timeout and retransmissions are
  handled
• Since a reliable protocol expects successfully
  received data to be acknowledged, the sender sets
  a timer denoting how long it will wait to
  determine the datas fate
• If an ACK for the data is received before the
  timer expires, the data was successfully received
• If the timer expires before the ACK returns, the
  data is assumed lost or corrupted and is
  retransmitted
• The key to efficiency is setting the right value
  for the timeout
• A timeout value too large will decrease
  efficiency
• A timeout value too small will increase
  retransmissions
• Ideally, a timeout value just larger than the
  expected Round Trip Time (RTT) is optimum

26
The Transmission Control Protocol (TCP)

• Timeout and Retransmission (continued)
• With TCP setting the timeout value is hard
  because the RTT can vary widely because of
  several factors
• Heterogeneous networks with varying delay times
• Dynamic routing protocols and paths
• Congestion
• To overcome this hurdle, TCP uses an adaptive
  retransmission algorithm to attempt to maintain
  an optimal timeout value
• TCP computes an elapsed time for the current
  round trip sample
• This time is averaged with the previous running
  average to compute a new estimated RTT for the
  connection (keeps the RTT calculation more
  stable)
• The first TCP Timeout calculations
• RTT (a ? old_RTT) ((1-?) ? current_RT) 1 ?
  a gt 0
• Timeout ? ? RTT (? ? 1)

27
The Transmission Control Protocol (TCP)

• Accurate Measurements of Round-Trip Times
• Though in theory the concept is simple, in
  practice it is much harder with TCP because of
  the cumulative acknowledgements
• Retransmissions with cumulative ACKs cause a
  condition called acknowledgement ambiguity --
  which transmission of the packet should be used
  for the RTT calculation?
• Choosing the original leads to timeouts that grow
  without bound
• Choosing the last retransmission leads to a
  stable but inefficient timeout
• The answer? Dont update the RTT/Timeout for
  retransmitted segments!
• There is an alternative mechanism to use called
  Karns algorithm -- this prevents the situation
  where doing nothing leads to a timeout value that
  grows without bound
• Karns algorithm
• When computing the RTT/Timeout, ignore samples
  that correspond to retransmitted segments, but
  use a backoff strategy and retain the timeout
  value from subsequent segments until a valid
  sample is obtained

28
The Transmission Control Protocol (TCP)

• An improvement to TCP to cope with high variance
  in Delays
• Research and experience demonstrated that the
  original RTT/Timeout calculations used for TCP
  could not adapt well to delay variations
• High variance in delay meant at medium to high
  network loads (gt 30) the estimated timeout
  values were inaccurate, reducing efficiency
• To improve efficiency the RTT/Timeout
  calculations were changed in 1989 to include a
  measure of RTT variance
• New RTT/Timeout Calculations
• DIFF Current_RTT - Old_RTT
• Smoothed_RTT Old_RTT (? ? DIFF) 0 lt ? lt 1
• DEV Old_DEV ?(?DIFF?- Old_DEV) 0 lt ? lt 1
• Timeout Smoothed_RTT (? ? DEV) ? ? 1
• Figures 13.11 13.12 illustrate that the new
  calculations work well, though there are always
  conditions under which the connection can suffer
  timeouts and retransmissions

29
The Transmission Control Protocol (TCP)

• TCP and its response to Congestion
• As stated earlier TCP must be able to react to
  congestion at intermediate nodes (typically
  routers) without hurting performance efficiency
• Definition of congestion a condition of severe
  delay caused by an overload of datagrams at one
  or more intermediate nodes
• With TCP excessive delays cause timeouts that
  trigger retransmissions
• Retransmissions exacerbate congestion instead of
  alleviating it
• If left unchecked the additional traffic causes
  congestion collapse and the throughput of the
  node (or network) falls to zero
• To reduce congestion TCP needs to reduce the data
  flow across the network
• TCP has no explicit congestion notification
  mechanism it is assumed that timeouts
  retransmissions are primarily due to congestion
• Therefore, TCP uses implicit congestion
  information to take action
• TCP has two important congestion control
  mechanisms slow start multiplicative decrease

30
The Transmission Control Protocol (TCP)

• TCP and its response to Congestion (continued)
• Slow start multiplicative decrease are related
  implemented together
• In addition to the receiver window advertisement,
  the sender in a TCP connection maintains a second
  window called the congestion window
• Therefore, the current allowed transmission
  window is
• min(receiver_advertisement, congestion_window)
• In normal operation, the two windows are equal,
  but when a segment is lost the congestion window
  is cut in half and the timeout is doubled
• The goal is to produce quick and significant
  traffic reduction before congestion becomes
  severe
• To avoid instability, TCP recovers from
  congestion by using a process called slow-start,
  which works by starting the congestion window at
  one segment and increasing it by one for every
  acknowledgement received
• Slow-start is not very slow, but it is compared
  to multiplicative decrease!
• One other rule is added, when the congestion
  window reaches half of its original size, the
  increase in the congestion window becomes linear

31
The Transmission Control Protocol (TCP)

• Congestion, Tail-Drop, and TCP
• For the most part TCP abides by strict layering
  in its protocol design in operation TCP rarely
  interacts with lower protocol layers
• Researchers have shown that the design
  implementation choices made in protocol
  development can have a dramatic effect on higher
  layers
• Example how routers manage their queues has a
  significant impact on TCP operation
• Early router implementations used a tail-drop
  policy to manage queues -- if the queue was full
  when a packet arrived it was discarded
• When such a queue carries packets from a single
  TCP connection, it causes the connection to go
  into slow-start
• When the queue carries packets from many TCP
  connections, it can cause a synchronization or
  oscillation condition where all the connections
  go into slow-start together
• Such actions can cause waves of congestion in a
  router

32
The Transmission Control Protocol (TCP)

• Random Early Discard (RED)
• Obviously oscillations in the data flow of TCP
  connections is not a good condition -- how can
  routers manage their queues more efficiently?
• An algorithm known as RED works very well and
  uses the following basic procedure for a newly
  arrived packet
• If the queue contains fewer than Nmin packets,
  add the packet to the queue
• If the queue contains more than Nmax packets,
  discard the packet
• If the queue contains between Nmin and Nmax
  packets, discard the newly arrived packet with
  probability p
• The key to making RED work well is the choice of
  thresholds and the discard probability p
• Nmin too low or p too high and the queue cannot
  accommodate short bursts
• Nmin too high or p too low and RED cannot react
  to congestion fast enough
• Using a weighted average for the discard
  probability helps RED work well
• RED favors small packets like ACKs -- this helps
  reduce congestion

33
The Transmission Control Protocol (TCP)

• Establishing a TCP Connection
• A three-way handshake is used to initialize a TCP
  connection
• The three-way handshake is necessary and
  sufficient for proper initialization of the
  connection
• Though the three-way handshake is the typical
  situation (one side waits passively while the
  other actively initiates the connection), TCP is
  designed to work in situations where both sides
  initiate it simultaneously
• Once the connection is established, there is no
  master or slave -- both sides are equally capable
  of transferring data
• The initial sequence numbers must be chosen
  randomly (or tied to the system clock) to prevent
  problems with abnormal operation and security
• During the initial handshake, both sides agree on
  the initial sequence numbers to be used in each
  direction
• Data can be carried in the three-way handshake,
  but it will not be available to the destination
  application until the handshake is complete

34
The Transmission Control Protocol (TCP)

• Establishing a TCP Connection
• Examples of opening a TCP connection Normal TCP
  Open

35
The Transmission Control Protocol (TCP)

• Closing a TCP Connection
• A modified three-way handshake is also used to
  close a TCP connection
• Even though a TCP connection is full-duplex, each
  side of the connection can be closed
  independently
• The FIN flag is used to signal that an endpoint
  wishes to close its end of a connection (i.e. -
  has no more data to send)
• Even though a minimum three segments can be
  exchanged, a normal TCP close typically has a
  exchange of four segments (Figure 13.14 below)

36
The Transmission Control Protocol (TCP)

• Closing a TCP Connection
• The FIN flag is used during the normal close of a
  TCP connection such as after finishing the
  transfer of a data file
• There are times when connections must be closed
  because of abnormal operational states
• An operation is abruptly aborted
• A network condition or error breaks a connection
• One endpoint thinks a connection is open that the
  other endpoint has marked as closed
• Under such circumstances the RST flag is used to
  signal an abnormal condition
• An endpoint receiving a segment with the RST flag
  set immediately aborts the connection
• All data transfer ceases immediately and
  resources such as transmit and receive buffers
  are released

37
The Transmission Control Protocol (TCP)

• The TCP State Diagram
• The state diagram is a complete specification of
  the possible states and transitions between
  states that can happen in a system
• How to read the state diagram
• Examples of TCP in action
• Example Open
• Example Close
• The Wait State and the 2MSL Timer
• MSL or Maximum Segment Lifetime is an estimate of
  the time a TCP segment can exist on the network
  before it is discarded
• The default MSL on many systems is either 60 or
  120 seconds
• Designed to protect a new connection against
  delayed TCP segments from a previously closed
  connection
• During the 2MSL wait state the TCP socket pair
  cannot be used (some TCP/IP stacks have more
  stringent restrictions)

38
The TCP State Diagram
39
The Transmission Control Protocol (TCP)

• More TCP Connection Examples
• Not so normal situations
• Half Open
• Half Close
• Simultaneous Open
• Simultaneous Close
• Abrupt Close (an Abort or Reset)

40
The Transmission Control Protocol (TCP)

• Forcing Data Delivery
• Use of the PUSH flag
• A mechanism for the sender to tell the receivers
  TCP process to send the data in the TCP segment
  to the receiving application process instead of
  letting it sit around in the receiving buffer
• While buffering of data improves network
  performance users of interactive applications
  want the connection to be responsive
• A little different than Urgent data
• This was meant to be a way to get around the byte
  stream service without having to have the
  application layer impose some kind of framing
  structure
• Sometimes the PUSH flag is set by the sending TCP
  process and sometimes it can be requested by the
  sending application (API dependent)

41
The Transmission Control Protocol (TCP)

• Silly Window Syndrome and Small Packets
• Researchers have learned that a phenomenon called
  Silly Window Syndrome (SWS) occurs with TCP when
  sending and receiving applications operate at
  different speeds
• The sending application soon fills up the
  receivers buffer, causing it to advertise a zero
  window
• Eventually the receiving application reads a byte
  of data from the buffer, allowing the receiving
  TCP process to advertise a nonzero window
• The sender is allowed to send a byte of data,
  closing the window again
• The process repeats, with very small segments
  transmitted at a very high cost to efficiency
• The sender can also cause a form of SWS if the
  sending application generates data one byte at a
  time and the sending TCP process does not wait
  for data to accumulate in the sending buffer
• To help combat SWS, a set of TCP implementation
  improvements were made to both the sending and
  receiving endpoints

42
The Transmission Control Protocol (TCP)

• Silly Window Syndrome and Small Packets
  (continued)
• Receive-side Silly Window avoidance
• To prevent small windows from being advertised,
  TCP has been modified so the receiver will wait
  until it can advertise a significant window
  size
• TCPs definition of significant is the minimum
  of one half the MSS and the receivers buffer
  size
• Delayed Acknowledgements
• In practice, there are two ways to implement
  receive-side silly window avoidance
• Acknowledge each segment that arrives, but delay
  advertising an increase in the window size
• Delay the ACK until a significant window size
  can be advertised
• The second method is preferred because it could
  eliminate an extra ACK
• The ACK cannot be delayed too long or the sender
  will time out the TCP standards place a 500ms
  time limit on delayed acknowledgements
• Also, every other segment should be ACKed to
  provide good RTT data

43
The Transmission Control Protocol (TCP)

• Silly Window Syndrome and Small Packets
  (continued)
• Send-side Silly Window Avoidance
• The sending TCP process must also undergo
  modification to avoid sending small segments
  (clumping of data)
• An elegant adaptive solution known as Nagles
  algorithm is now used
• When a sending application generates additional
  data to be sent over a connection for which
  previous segments have been sent but not ACKed,
  place the data in the output buffer but do not
  send additional segment until an ACK arrives or
  when an MSS amount of data has accumulated
• Nagles algorithm has a very important property
  called self-clocking
• The faster ACKs arrive the faster data can be
  sent
• Adapts to a variety of network conditions
• Adds little computational overhead
• Does not interfere with the efficiency of
  high-throughput applications
• Also handles interactive applications well (e.g.
  terminal applications)

44
The Transmission Control Protocol (TCP)

• More functionality the TCP Persist Timer
• Used to prevent deadlock when the receiver is
  advertising a zero window and the
  acknowledgements that would normally open the
  advertised window are lost
• The persist timer prompts the sender to, in the
  absence of any acknowledgements (alone or
  piggybacked on data) query the receiver for the
  current window size
• This process is known as a window probe
• An exponential backoff algorithm is used to
  minimize the traffic generated by window probes
  up to an interval of 60 seconds at that point
  window probes are sent every 60 seconds until the
  window opens or the connection is terminated

45
The Transmission Control Protocol (TCP)

• More functionality TCP Keepalives
• Keepalives provide a means for determining that
  the other end of a connection is still present
  when a connection is idle for long periods of
  time
• A valid TCP connection may not send data for a
  long time, so a Keepalive is just a way of making
  sure that the other endpoint in a connection is
  still functional and participating in the
  connection
• Keepalives are not part of the TCP RFP or the
  Host Requirements RFC but they are widely used
• The keepalive timer is typically set for two
  hours if no data is sent on the connection
  after 120 minutes the timer expires, a keepalive
  is sent, and the timer is reset
• If a response to the keepalive is not received
  the sender will typically try resending the
  keepalive about 10 times (75 seconds apart)
  before declaring the connection dead

46
The Transmission Control Protocol (TCP)

• More functionality TCP Keepalives (continued)
• Advantages of the TCP Keepalive
• Helps prevent server resources from being wasted
  on half open connections
• Disadvantages of the TCP Keepalive
• It can cause perfectly good TCP connections to be
  dropped because of transient network failures
• It uses up unnecessary network bandwidth
• It costs money on any parts of the network that
  charge for usage (very unusual today)

47
The Transmission Control Protocol (TCP)

• Three Final points on the TCP protocol
• Despite all the tweaks and modifications made to
  TCP it remains a surprisingly efficient and
  elegant protocol
• Though sometimes overlooked, researchers have
  shown that TCP connections can provide very high
  throughput
• It has been shown that a TCP connection can
  sustain 8-Mbps throughput on an Ethernet
• Over very high speed infrastructures gigabit
  speeds have been approached with TCP connections
• To this day TCP research and enhancements
  continue to be suggested and considered for
  incorporation in the protocol
• Selective Acknowledgements (RFC 2018)
• Explicit Congestion Notification (RFC 3168)

48
Important Implementation Details for TCP and UDP

• TCP and UDP applications use the client-server
  paradigm
• TCP and UDP transport services are accessed
  through an API typically called the Sockets API
• A socket provides an interface similar to the
  UNIX file access mechanism, where a file
  descriptor (or file handle) is used for all
  actions that must reference that file
• The Sockets API is not a published uniform
  standard it is a de facto standard whose
  implementation details can vary from system to
  system
• Sockets were designed to be used with other
  transport protocol families such as Appletalk,
  but is well-known because of its association with
  TCP/IP
• In some systems Sockets can be implemented as a
  set of library functions instead of part of the
  kernel this can lead to different behavior when
  designing a networked application

49
UDP client-server applications

• With UDP it is the responsibility of the
  application to determine what different data
  flows are coming through its port
• In general UDP servers, just like the protocol,
  are meant to be simple with low overhead and
  system requirements
• UDP servers processes are typically iterative by
  design
• An iterative server process will handle all UDP
  traffic on a port from multiple client processes
• Data from multiple clients will be handled in a
  first-come first-served fashion
• All clients using the UDP server process on a
  port will be using a shared buffer if the
  software designer is not careful this could cause
  problems with buffer overruns

50
UDP client-server applications

• UDP servers processes typically operate using the
  following Sockets API calls
• Create the socket (specifying the protocol to
  use)
• Bind the socket to the local IP address and port
• Listen for incoming requests (typically defines
  the queue size for the socket)
• Read any incoming data (may be interrupt driven
  or polled)
• Write any responses
• Terminate the socket if the server process is
  shut down
• General Notes
• The same function call can be used for TCP or UDP
• The API could be used for other protocols
• Need to be careful on multi-homed hosts

51
UDP client-server applications

• UDP clients typically access a server using the
  following Sockets API procedure calls
• Create the socket
• Bind the socket to the local IP address and a
  (typically random) port number
• Read and write data until done
• Terminate the socket when the client process has
  completed its communication

52
TCP client-server applications

• With the TCP connection abstraction it is easy to
  identify different data flows for the same
  application
• In general, TCP server processes are meant to be
  much more sophisticated than UDP servers --
  providing more functionality but with much more
  overhead and higher system requirements
• TCP server processes are typically concurrent by
  design
• Concurrent servers run a parent process initiated
  at the startup of the server
• A child process is spawned to handle each TCP
  connection
• Each child process has its own queues and buffer
  space
• Termination of a child process does not affect
  other active TCP connections

53
TCP client-server applications

• TCP servers processes typically operate using the
  following Sockets API procedure calls
• Create the socket
• Bind the socket to the local IP address and a
  well-known port number
• Listen for incoming connection requests
• Accept an incoming request and spawn a child
  process to handle it
• Data written and read through child process
• Connection closed and child process terminated
  when application is done with communication
• Parent process terminated when server process is
  shut down

54
TCP client-server applications

• TCP clients typically access a server using the
  following Sockets API procedure calls
• Create the socket
• Bind the socket to the local IP address and a
  well-known port number
• Initiate a connection to the TCP server process
  upon request of the application
• Read and write data if connection is accepted by
  the server
• Close the connection and terminate the process
  upon completion of communication

55
Reading Homework

• Reading for this class
• Chapters 11 and 12 with basic info from Chapter
  21
• Homework 2 (due Monday 6/18) (Problems 66
  of grade)
• Chapter 9 9.3, 9.4, and 9.15
• Chapter 11 11.2
• Chapter 12 12.4, 12.8, 12.10, 12.14
• Chapter 13 13.5 and 13.8
• (33) Download a packet sniffer like Ethereal
  (www.ethereal.com) and use it to complete the
  following (with the sniffer running, of course!)
• Do a traceroute to www.umd.edu. What frame
  types do you capture? Can you determine the
  manufacturer of the network interface your
  machine is communicating with over the LAN?
  Which networks you cross to reach www.umd.edu?
• Start a web browser go to http//www.wtop.com
  how many TCP connections are generated with that
  request? Which TCP options (if any) do you see
  in the segments?
• In the course of capturing any traffic do you
  capture any UDP packets? What are they used
  for? Is the UDP checksum generated in any of the
  packets?
• Let your sniffer run for a while, do you see any
  IP broadcast or multicast traffic? What is it
  used for?