ISO (International standards organization)/OSI (open systems interconnections)

reference model
-Defines what operations should occur at different layers of a network
 Application: Supporting network applications
 Presentation (How the data is presented on a specific device/application): Allow
applications to interpret the “meaning” of data (e.g. encryption, compression, machine-
specific conventions)
 Session (Tracks progress of data exchange): Synchronization, check-pointing, recovery
of data exchange
 Transport (specific process running): Process-process data transfer
 Network (moving data from source to next switch/hop to end point in most efficient
way): Routing of datagrams from source to destination
 Link(Only worried about one device to next device): Transfer between neighbouring
network elements
 Physical (how data is encoded on physical medium): Encoded bits “on the wire”

Internet protocol stack and TCP/IP suite:

 Application: FTP/SMTP/HTTP
 Transport: TCP/UDP (establishes process to process connection)
 Network: IP/ routing protocols (Allows us to find path from host to destination device)
 Link: Ethernet/wifi (Allows us to send traffic between adjacent nodes)
 Physical: Whichever medium is used (Translates bits of digital information to an actual
signal)

Internet protocol stack is the presentation and session layers, if these services are needed, they
must be implemented in the application layer

Encapsulation
 At the application layer a message is generated by the application being used on the
source device
 The application layer passes the message down to the transport layer
 Transport layer receives the message and encapsulates (puts the message into a transport
layer envelope) it in its own header(adds required information such as port number etc)
now referred to as a segment
 The segment is passed down to the network layer which encapsulates it further by adding
another header (required information e.g. IP addresses [source and destination]) now
referred to as a datagram/packet
  Datagram is passed down to link layer, encapsulates it further, adds a header (physical
address such as a specific router or interface), now called a frame
 Frame passed down to physical layer which sends it to a switch
 Frame is passed up to link layer to determine next device to receive message
 Pushed back down to physical and hits next link (e.g. router)
 Message is pushed up to network layer, back down to physical layer and is sent to
destination device
 Destination device decapsulates the frame to return it back to a message by going up the
layers

What’s a protocol?
 Rules for specific messages sent
 Rules for specific actions taken when message received or other events

Protocols define the format, order of messages sent and received among network entities and
actions take on message transmission receipt

Network protocols:

 Computer (devices) rather than humans

 All communication activity in internet governed by protocols

Internet structure:
Network edge:

 Hosts: Clients and servers (in homes, businesses, data centers for servers)

Access networks, physical media (sometimes called edge network):

 Wired or wireless communication links

Network core:

 Interconnected routers
 Network of networks

Internet structure: A “network of networks”

 Hosts connect to internet via access internet service providers (ISP)
  Access ISPs in turn must be interconnected (so that any two hosts anywhere can send
packets to eachother)
 Resulting network if networks is very complex (evolution is driven by economics,
national policies etc)
 End systems are connected together by network of communication links and packet
switches

The Network core:

 A mesh of interconnected routers
 Packet-Switching = hosts break application layer messages into packets
 Network forwards packets from one router to the next, across links on path from source
to destination

Two key network-core functions to allow this:

 Routing algorithms (and routing overall) to figure out the best path before starting
delivery
 Forwarding aka “switching”, a local action to move arriving packets from router’s input
link to appropriate router output link (the destination address is in the arriving packet’s
header), creates a forwarding table where the header value relates to an output link
 Routing is a global action which determines the source-destination path taking by packets

Packet-switching: Store and forward

 Each packet (made up of several bits) as it’s coming arrives at a router

 Packet transmission delay: takes L(# of bits)/R (# of bits that can be sent per second)
seconds to transmit (push out) L-bit packet into link at R bps (bits per second)
 E.g.
L = 10 Kbits
R = 100 Mbps
One-hop transmission delay = 0.1 Msec
 Store and Forward: Entire packet must arrive at router before it can be transmitted on
next link
e.g. if R(incoming)=100 Mb/s but R(outgoing) only = 1.5Mb/s the packets will have to
queue to wait for transmission over the output link
 Packet queuing and loss: If arrival rate (in bps) to link exceeds transmission rate (bps) of
link for some period of time:
-Packets will queue waiting to be transmitted
-Packets can be dropped (lost) if memory (buffer) in router fills up

How do packet delay and loss occur?

  Packets queue in router buffers waiting for turns for transmission
-Queue length grows when arrival rate to link (temporarily) exceeds output link capacity
 Packet loss occurs when memory to hold queued packets fills up

Packet Delay (4 sources):

 Processing delay (time it takes a router to read a packet’s header information and look in
the forwarding table for which output queue it should be in)
 Transmission delay: time taken for packet to be taken from queue and pushed out on link
= (L/R)
 Queuing delay: How long a packet stays in queue
 Propagation delay: How long it takes for data to move from source router to receiving
router = d/s (d = distance, s = propagation speed)
 Packet delay:
d(nodal) = d(proc) + d(queue) + d(trans) + d(prop)

Packet queuing delay (revisited):

 a: average packet arrival rate

 L: Packet length (bits)
 R: Link bandwidth (bit transmission rate)
 L.a / R = traffic intensity = arrival rate of bits / service rate of bits
- if L.a / R ~ 0: avg queuing delay is small
- if L.a / R Is approaching 1, avg queuing delay is large
-If L.a / R is larger than one, you’ll have a huge queue (and will become infinite)

“Real” Internet delays and routes:

 Traceroute program: provides delay measurement from source to router along end-end
internet path towards destination. For all i:
-Sends three packets that will reach router i on path towards destination (with time to
live field value of i, each router decrements the time-to-live value by 1)
-Router i will return packets to sender
-Sender measures time interval between transmission and reply

Throughput:

 Throughput: rate (bits/time unit) at which bits are sent from sender to receiver
-Instantaneous: rate at given point in time
-Average rate over longer period of time
 Bottleneck link – Link that puts a constraint on end-end throughput (the link with a
lower throughput)
  In reality if there are multiple connections: end-end throughput the minimum of all the
throughputs over the number of connections
 In practice R (source to link) or R(receiver link) is the bottleneck

Application Layer:

Client-Server Paradigm:
Server:

 Always-on host
 Permanent IP address
 Often in data centers for scaling

Clients:

 Contact, communicate with server

 May be intermittently connected
 May have dynamic IP addresses
 Do not communicate directly with eachother
 E.g. HTTP, IMAP, FTP

Peer-Peer architecture:
 No always-on server
 Arbitrary end systems directly communicate
 Peers request service from other peers, provide service in return to other peers (self
scalability = new peers bring new service capacity as well as new service demands)
 Peers are intermittently connected and change IP addresses (have complex management)
 E.g. P2P file sharing

Process Communicating:

Process = program running with a host

 Within same host, two processes communicate via inter-process communication (defined
by OS)
 Processes in different hosts communicate by exchanging messages
 Client process = process that initiates contact
 Server process = process that waits to be contacted
 P2P programs have client processes and server processes

Sockets
  A process sends/receives messages to/from its socket
 Socket is similar to a door:
-Sending process shoves message out of door
-Sending process relies on transport infrastructure
-Two sockets are involved, one on each end

Addressing processes:
 To receive messages, process must have an identifier
 Host device has a unique 32 bit IP address
 Many processes can be running on one host
 Identifiers include both IP address and port number associated with the process on the
host

What transport service does an app need?

 Data integrity
-Some apps require 100% reliable data transfer
-Other apps can tolerate some loss
 Timing:
-Some apps require low delay to be effective
 Throughput:
-Some apps require minimum amount of throughput to be effective
-Other apps (“elastic apps”) make use of whatever throughput they get
 Security
-Encryption, data integrity etc

Internet transport protocols services:

 TCP(Transmission Control Protocol) Service:
-Reliable transport: Between sending and receiving process
-Flow control: Sender won’t overwhelm receiver
-Congestion control: Throttle sender when network overloaded
-Connection-oriented: Setup required between client and server processes
-Does not provide: Timing, minimum throughput guarantee or security
 UDP(User datagram protocol) Service:
-Unreliable data transfer: Between sending and receiving process
-Does not provide: reliability, flow control, congestion control, timing, throughput
guarantee, security or connection setup
-Is faster (higher throughput)

Socket Programming:
  Two socket types for two transport systems:
-UDP: Unreliable datagram
-TCP: Reliable, byte stream-oriented

Socket programming with UDP:

 UDP no “connection” between client and server:
-No handshaking before sending data
-Sender explicitly attaches IP destination address and port # to each packet
-Receiver extracts sender IP address and port# from received packet
 UDP: Transmitted data may be lost or received out of order
 Application viewpoint:
-UDP provides unreliable transfer of groups of data (“Datagrams”) between client and
server processes

Socket programming with TCP:

 Client must contact server:
-Server process must first be running
-Server must have created socket that welcomes client’s contact
 Client contacts server by:
-Creating TCP socket, specifying IP address and port # of server process
-When client creates socket: client TCP establishes connection to server TCP
 When contacted by client, server TCP creates new socket for server process to
communicate with that specific client:
-Allows server to talk with multiple clients
-Source port numbers used to distinguish client
 TCP provides reliable, in order byte-stream transfer (pipe) between client and server

Application-layer protocol defines:

 Type of message exchanged (e.g. request, response)
 Message syntax (what fields in messages and how fields are delineated
 Message semantics: meaning of information in fields
 Rules for when and how processes send/responsed to messages
 Open protocols: Defined in RFCs, everyone has access to protocol definition
 Proprietary protocols: Can only be used by one specific company, is not public use (e.g.
skype)
Web and HTTP
 Web page consists of objects, each of which are stored on different web servers
 Object can be html file, jpeg image, java applet etc
 Web page consists of base HTML-file which includes several referenced objects, each
addressable by a URL

HTTP Overview
 HTTP = Hyper text transfer protocol
 Web’s application layer protocol
 Client/server model:
-Client: Browser that requests, receives (using HTTP protocol) and displays web object
-Server: Web server sends (using HTTP protocol) objects in response to requests
 HTTP uses TCP:
 Client initiates TCP connection(creates socket) to server, port 80
 Server accepts TCP connection from client
 HTTP messages (application layer protocol message) exchanged between browser
(HTTP client) and Web server
 TCP connection closes
 HTTP is stateless: server maintains no information about past client requests
 Protocols that maintain “state” are complex:
-History must be maintained
-if server/client crashes their views of “state” may be inconsistent and must be fixed

HTTP connections: 2 types

Non persistent HTTP:

 TCP connection opens

 At most one object sent over TCP connection
 TCP connection closes
 Downloading multiple objects required multiple connections

Persistent HTTP:

 TCP connection opened to a server

 Multiple objects can be sent over single TCP connection between client and server
 TCP connection closes

Non-Persistent HTTP response time:

  RTT(Definition): time for a small packet to travel from client to server and back
 HTTP response time (per object):
-One RTT to initiate TCP connection
-One RTT for HTTP request and first few bytes of HTTP response in returns
-Object/file transmission time
 None-persistent HTTP response time = 2RTT+File transmission time

Persistent HTTP:
 Non-persistent HTTP issues:
-Requires 2 RTTs per object
-OS overheads for each TCP connection
-Browsers often open multiple parallel TCP connections to fetch referenced objects in
parallel
 Persistent HTTP:
-Server leaves connection open after sending response
-Subsequent HTTP messages between same client/server are sent via open connection
-Client sends requests as soon as it encounters a referenced object
-As little as one RTT for all the referenced objects

HTTP Request message:

 Two types of HTTP messages: request & response
 HTTP request message
-ASCII (human readable)
Other HTTP request messages:
 POST method:
-Web page often includes form input
-User input sent from client to server in entity body of HTTP POST request message
 Get Method (for sending data to server):
-Include user data in URL field of HTTP get message following a “?” (e.g.
http://www.somesite.com/animalsearch?monkeys&banana)
 HEAD method:
-Requests headers only, that would be returned if specified URL were requested with an
HTTP GET method
 PUT method:
-Uploads new file (object) to server
-Completely replaces file that exists at specified URL with content in entity body of
POST HTTP request message

HTTP response status codes:

 200 OK:
-request succeeded, requested object later in this message
 301 Moved Permanently:
-Requested object moved, new location specified later in this message
 400 Bad Request:
-Request message not understood by server
  404 Not Found
-Requested document not found on this server
 505 HTTP version not supported

Maintaining user/server state: Cookies

 Websites and client browsers use cookies to maintain some state between transactions
 Four main components:
1. Cookie header line of HTTP response message
2. Cookie header line in next HTTP request message
3. Cookie file kept on user’s host, managed by user’s browser
4. Back-end database at web site

HTTP cookies: Comments

What cookies can be used for:

 Authorization
 Shopping carts
 Recommendations
 User session state (web emails)

How to keep state:

 At protocol endpoints: Maintain state at sender/receiver over multiple transactions

 In messages: Cookies in HTTP messages carry state

Web Caches:
Goal: Satisfy client requests without involving origin server

 User configures browser to point to a local web cache

 Browser sends all HTTP requests to cache
-If object is in cache, cache returns object to client
-Else cache requests object from origin server, caches received object and returns object
to client

Web Caches (Proxy servers):

 Web cache acts both as client and server:
-Server for original requesting client
-Client to origin server
 Server tells cache about object’s allowable caching in response header
 Why use web caching?
-Reduce response time for client (since cache is closer to client)
-Reduce traffic on an institutions access link
-Internet is dense with caches, enables “poor” content providers to more effectively
deliver content
Conditional GET:
 Goal: Don’t send object if cache has up-to-date cached version
-No object transmission delay(Or use of network resources)
 Client: Specify date of cached copy in HTTP request:
-If-modified-since: <date>
 Server: Response contains no object if cached copy is up to date:
-HTTP/1.0 304 Not Modified

DNS: Domain Name System

 People: Many identifiers:
-SSN, Name, Passport #
 Internet hosts, routers:
-IP address(32 bit) used for addressing datagrams
-“Name” e.g. umass.edu (used by humans)

DNS:

 Distributed database implemented in hierarchy of many name servers

 Application layer protocol: Hosts, DNS servers communicate to resolve names
(address/name translation)
-Core internet function (implemented as application layer protocol)
-Complexity at network’s “edge”

DNS Services, structure

DNS Services:

 Hostname-to-IP-Address translation
 Host aliasing (canonical, alias names)
 Mail server aliasing
 Load distribution (replicated web servers: Many ip addresses correspond to one name)

Why not centralize DNS?

 Single point of failure

 Traffic volume
 Distant centralized database
 Maintenance
 Doesn’t scale!!

Thinking about DNS

  Humungous distributed database
 Handles trillions of queries a day (mainly reads more than writes)
-Performance matters, almost every internet transaction interacts with DNS (msecs
count!)
 Organizationally, physically decentralized:
-Millions of different organizations are responsible for their records
 “Bulletproof”: reliability and security

DNS Hierarchy:
1. Root
2. Top Level Domain
3. Authoritative

DNS: Root name servers

-Official, contact of last resort by name servers that cannot resolve name

 Incredibly important internet function

-Internet can’t function without tit
-DNSSEC – provides security (authentication/message integrity)
 ICANN (Internet corporation for assigned names and numbers) manages root DNS
domain

Top Level Domain and authoritative servers:

 Top Level Domain (TLD) servers:
-Responsible for .com, .org, .net. edu (and all top country domains) e.g. .uk, . ca, .fr etc
-Network solutions: Authoritative registry for .com, .net TLD
-Educase: .edu TLD
 Authoritative DNS servers:
-Organizations own DNS server, providing authoritative hostname to IP mappings for
organizations named hosts
-Can be maintained by organization or service provider

Local DNS name servers:

 When Host makes DNS query it is sent to its local DNS server
-Local DNS server returns reply answering: From its local cache of recent name to
address translation pairs (may be out of date) and forwarding request into DNS hierarchy
for resolution
 Each ISP has local DNS name server
 Local DNS server doesn’t strictly belong to hierarchy
DNS Name resolution: Iterated query
 Iterated query:
-Contacted server replies with name of server to contact which holds the IP requested
(e.g. local contacted server will reply with name of either root, TLD or authoritative
server which holds requested IP address) visits root then returns to local, visits TLD then
returns to local etc.

DNS name resolution: Recursive query

 Puts burden of name resolution on contacted name server
 Request sent to local, visits root server, from root visits TLD, from TLD visits
authoritative, returns message in same order

Caching DNS Information

 Once any name server learns mapping it caches mapping and immediately returns a
cached mapping in response to a query
-Caching improves response time
-Cache entries timeout (disappear) after some time (TTL)
-TLD Servers typically cached in local name servers
 Cached entries may be out of date
-If named host changes IP address, may not be known internet wide until all TTLs expire

DNS Records
DNS: Distributed database storing resource records(RR)
RR format: (name, value, type, ttl)

 Type=A
-name is hostname
-value is IP address
 Type = CNAME
-name is alias name for some canonical (real) name
-e.g. www.ibm.com is really servereast.backup2.ibm.com
-value is canonical name
 Type = NS
-name is domain (e.g. foo.com)
-value is hostname of authoritative name server for this domain
 Type=MX
-value is name of SMTP mail server associated with name

DNS protocol messages:

Getting info into the DNS:
-Register name (e.g. utopia.com) at DNS registrar (e.g. network solutions)
-Provide names, IP addresses of authoritative name server (primary and secondary)
-registrar inserts NS, A RRs into .com TLD server:
(utopia.com, dns1.utopia.com, NS)
(dns1.utopia.com, 212.212.212.1 A)

-Create authoritative server locally with same IP address

-Type A record for www.utopia.com
-type MX record for utopia.com
Transport Layer
 Critical role of providing communication services directly to the application processes
running on different hosts
 Critical function of the transport layer: Extending the network layer’s delivery service
between two end systems to a delivery service between two application-layer processes
running on the end systems

Intro to Transport-Layer Services

 A transport layer protocol provides for logical communication between application
processes running on different hosts
 Application processes use the logical communication provided by the transport layer to
send messages to eachother free from the worry of details of physical infrastructure used
to carry these messages
 Transport layer protocols are implemented in the end systems but not in the network
routers, on the sending side the transport layer converts the application layer messages it
receives from a sending application process into transport layer packets, known as
segments
 Segments are then passed to the network layer at the sending end system where the
segment is encapsulated within a network layer packet (Datagram) and sent to the
destination
 On receiving side, network layer extracts the segment from the datagram and passes the
segment up to the transport layer
 Transport layer processes received segment making data in the segment available to the
receiving application
 Transport layer protocol provides logical communication between processes on
different hosts while network layer protocol provides logical communication
between hosts
 Transport layer protocols live in end systems
 Within an end system a transport protocol moves messages from application processes to
the network layer and vice versa but does not have any say about how messages are
moved within the network core
 A computer may take available multiple transport protocols with each protocol offering a
different service model to applications
 Transport protocol can offer reliable data transfer service to an application even when the
underlying network protocol is unreliable (even when the network protocol loses, garbles
or duplicates packets)
 Transport protocol can use encryption to guarantee the application messages are not read
by intruders even when the network layer cannot guarantee confidentiality of segments

Overview of transport layer in the internet

  UDP which provides an unreliable, connectionless service to the invoking application
 TCP which provides reliable connection-oriented service to invoking application
 TCP and UDP packets are referred to as segments and “datagram” is reserved for the
network layer packet
 Internet network layer protocol has a name IP (internet protocol)
 IP provides logical communication between hosts
 IP service model is a best effort delivery service (IP makes “best effort” to deliver
segments between hosts but does not guarantee delivery, order or integrity of data in the
segments)
 IP is thus said to be an unreliable service
 Each host has an IP
 Most fundamental responsibility of UDP and TCP is to extend IP delivery service
between two end systems to a delivery service between two processes running on end
systems
 Extending host to host delivery to process to process delivery is calling transport layer
multiplexing and demultiplexing
 UDP and TCP also provide integrity checking by including error detection fields in their
segment’s headers
 These two minimal transport layer services (process to process data delivery and error
checking) are the only two UDP provides
 UDP is an unreliable service it does not guarantee that data send by one process will
arrive intact or at all
 TCP provides reliable data transfer
 TCP ensures data is delivered correctly and in order
 TCP thus converts IP’s unreliable service into a reliable data transport service
 TCP provides congestion control
 TCP congestion control prevents any on TCP connection from swamping the links and
routers between communicating hosts with excessive traffic
 TCP strives to give each connection traversing a congested link an equal share of link
bandwidth
 An application using UDP can send at any rate it pleases for as long as it pleases
 A protocol that provides reliable data transfer and congestion control is complex

Multiplexing and Demultiplexing:

 Extending the host to host deliver service provided by the network layer to a process to
process for applications on each host = multiplexing/demultiplexing
 At the destination host, the transport layer receives segments from the network layer
below
 Transport layer has the responsibility of delivering data in these segments to the
appropriate application process running in the host
 Transport layer in receiving host does not actually deliver data directly but instead
through an intermediary socket
 Each socket has a unique identifier
 At the receiving end, the transport layer examines these fields to identify the receiving
socket and direct the segment to that socket
 The job of delivering data to the correct socket = demultiplexing
 The job of gathering data chunks at the source host from different socket, encapsulating
each data chunk with header information to create segments and passing the segments to
the network layer is multiplexing
 Transport layer multiplexing requires that sockets have unique identifiers and that each
segment has special fields which indicate the socket to which the segment must be
delivered
 These special fields are the source port number field and destination port number field
 Each port number is a 16 bit number
 The port numbers ranging from 0-1023 are called well known port numbers and are
restricted for use by well known application protocols such as HTTP/FTP
 Demultiplexing service: Each socket in the host could be assigned a port number and
when a segment arrives at the host, the transport layer examines the destination port
number in the segment and directs it to the corresponding socket
 The segment’s data then passes through the socket into the attached process
 UDP socket is fully identified by a two-tuple consisting of a destination IP address and
destination port number
 As a consequence if two UDP segments have different source IP addresses and/or the
source port numbers but have different destination IP addresses and port #s then the two
segments will be directed into the same destination process via the same destination
socket
 Source port numbers serves as part of a “return address”
 TCP socket is identified by a four-tuple (Source IP, source port #, dest IP, dest port #)
 Two arriving TCP segments with different source IPs or port #s will be directed to two
different sockets (with the exception of a TCP segment carrying the original connection
establishing request)
 A connection-establishment request is nothing more than a TCP segment with dest. Port #
12000 and a special connection establishment bit set in the TCP header
 The transport layer at the server notes the following four values in the connection request
segment:
1: The source port number
2. The IP of source host
3. The destination port #
4. It’s own IP address
 When a TCP segment arrives at the host, all 4 fields are used to direct (demultiplex) the
segment to the appropriate socket
  The server distinguishes the segments from different client using source IP & port #
 Today’s high performing web servers only use one process and create a new thread with
a new connection socket for each new client
 At any given time there may be many connection sockets with different identifiers
attached to the same socket
 If the client and server are using persistent HTTP then throughout the duration of the
persistent connection the client and server exchange HTTP messages via same socket
 If they are using non-persistent HTTP then a new TCP connection is created and closed
for every request/response

Principles of Reliable Data Transfer:

 With a reliable channel, no transferred data bits are corrupted (flipped from 0 to 1 or vice
versa) or lost and all are delivered in the order sent
 This is precisely the service model offered by TCP
 Reliable data transfer protocol implement this service abstraction
 This task is made difficult by the fact that the layer below the protocol may be unreliable
 Unidirectional data transfer: is data transfer from the sending to the receiving side
 Bidirectional data transfer is conceptually no more difficult but is harder to explain
 Note that the sending and receiving sides of our protocol will need to transmit packets in
both directions

RDT 1.0:

 The sending side of reliable data transfer (rdt) accepts data from the upper layer via
rdt_send(data) event, creates a packet containing the data via (make_pkt(data)) and sends
the packet into the channel
 In practice the rdt_send(data) event would result from a procedure call (for example, to
rdt_send()) by the upper layer application
 On the receiving side, rdt receives a packet from the underlying channel via
rdt_rcv(packet) event and removes data from the packet via the extract(packet,data)
action, and passes data up to the upper layer
 In this simple protocol there is no different between a unit of data and a packet
 All packet flow is from sender to receiver with a perfectly reliable channel there is no
need for the receiver side to provide any feedback to the sender

RDT 2.0:

 A more realistic model is one in which bits in a packet may be corrupted

 Such bit errors typically occur in physical components as a picket is transmitted,
propagates or is buffered
 Positive acknowledgements (“OK”) and negative acknowledgements (“Please repeat
that”) are used in this protocol
  These control messages allow the receiver to let the sender know what has been received
correctly and what has been received in error requiring repeating
 In a computer network setting, reliable data transfer protocols based on such
retransmission are known as ARQ (Automatic Repeat reQuest) protocols

Three additional protocol capabilities required in ARQ protocols:

 Error detection: A mechanism is needed to allow the receiver to detect when bit errors
have occurred (e.g. the internet checkmsum field is used by UDP). These techniques
require extra bits be sent from the sender to the receiver to be gathered into the checksum
field
 Receiver feedback: Receiver provides explicit feedback to the sender. The positive
(ACK) and negative (NAK) acknowledgement replies in the message dictation scenario
are examples of feedback
 Retransmission: A packet received in error at the receiver will be retransmitted by the
sender

 The sender knows that the most recently transmitted packet has been received correctly
and thus the protocol returns to the state of waiting for data from the upper layer
 If a NAK is received, the protocol retransmits the last packet and waits for an ACK or
NAK to be returned by the receiver in response to the retransmitted data packet
 It is important to note that when the sender is in the wait-for-ACK-or-NAK state it cannot
get more data from the upper layer
  The sender will not send a new piece of data until it is sure that the receiver has correctly
received the current packet, as a result protocols such as RTD2.0 are known as stop-and-
wait protocols
 The receiver-side for RDT.20 still has a single state
 The receiver replies with either an ACK or NAK depending on whether the received
packet is corrupted
 RDT2.0 has a flaw, we haven’t accounted for if the ACK and NAK packet are corrupted
 If ACK/NAK packet is corrupted the sender won’t know if the receiver has correctly
received last piece of data transmitted

Three possibilities for handling corrupted ACK/NAKs:

 Receiver would repeat the reply with “What did you say” packet
 Add enough checksum bits to allow the sender to detect and recover from bit errors
 Sender resends the current data packet when it receives a garbled ACK/NAK packet, this
introduces duplicate packets, receiver however then doesn’t know whether the ACK or
NAK it last sent was received properly

 Simple solution: Add a new field to the data packet and have the sender number its data
packets by putting a sequence number into this field
 For our simple case of stop-and-wait, a 1-bit sequence number will suffice to let the
receiver know whether the sender is resending the previously transmitted packet or anew
packet
 RDT2.1 uses both positive and negative acknowledge from the receiver to the sender
 When an out of order packet is received the receiver sends a positive acknowledgement
for the packet it has received
 When a corrupted packet is received the receiver sends a negative acknowledgement
 Sender that receives two ACKs for the same packet (receives duplicate ACKs) knows
that the receiver did not correctly receive the packet following the packet that is being
ACKed twice
 Receiver must now include the sequence number of the packet being acknowledged by
the ACK message
 Sender must now check the sequence number of the packet being acknowledged by a
received ACK message

 How to detect packet loss and what to do when packet loss occurs:
 Use of checksumming, sequence numbers, ACK packets and retransmissions will allow
us to answer the latter concern
 The protocol should ideally recover from packet loss as soon as possible; waiting for a
worst case delay could mean a long wait until recovery is initiated
 The approach adopted is for the sender to judiciously choose a time value such that
packet loss is likely although not guaranteed to have happened
 If an ACK is not received within this time the packet is retransmitted
 If a packet experiences a particularly large delay the sender may retransmit the packet
even though neither the packet nor its ACK have been lost
 This introduces the possibility of duplicate data packets in the sender-to-receiver channel
 The sender does not know whether a data packet was lost, an ACK was lost or if the
packet or ACK was simply delayed
 In all cases the action is the same, retransmit. Implementing a time-based retransmission
machnism requires a countdown timer that can interrupt the sender after a given amount
of time
 The sender will need to be able to start the timer each time a packet is sent
 Respond to a timer interrupting
 Stop the timer
 The receive time for a packet is necessarily later than the send time for a packet as a
result of transmission and propagation delays
 Because pattern sequence numbers alternate between 0 and 1, RDT 3.0 is sometimes
known as alternating protocol
 The solution to this performance problem is for the sender to send multiple packets
without waiting for acknowledgements
 Since the many-in transit sender to receiver packets can be visualized as filling a pipeline
this technique is called pipelining and has the following consequences:
-Range of sequence numbers must increase
-Sender and receiver may have to buffer more than one packet
 -Range of sequence numbers needed and buffering requirements depend on the manner in
which a data transfer protocol responds to lost, corrupted and overly delayed packets, the
two basic approaches being “Go-Back-N” and “Selective repeat”

Go-Back-N(GBN):
 The sender is allowed to transmit multiple packets (when available) without waiting for
acknowledgment but is constrained to some maximum allowable number, N, for
unacknowledged packets in the pipeline
 “base” = number of the oldest unacknowledged packet and “next seqnum”= smallest
unused sequence number (that is, the sequence number of the next packet to be sent),
then four intervals in the range of sequence numbers can be identified
 The range of permissible sequence numbers for transmitted but not yet acknowledged
packets can be viewed as a window of size N over the range of sequence numbers
 N is often referred to as the window size and the GBN protocol itself is as a sliding
window protocol
 A packet’s sequence number is carried in a fixed length field in the packet header
 RDT3.0 had a 1 bit sequence number and a range of [0,1]
 TCP has a 32 bit sequence number field where TCP sequence numbers count bytes in the
byte stream rather than packets
 The GBN sender must respond with three types of events:
-Invocation from above: When rdt_send() is called from above the sender first checks to
see if the window is full, if the window is not full a packet is created and sent and the
variables are appropriately updated, if the window is full the sender simply returns the
data back to the upper layer, an implicit indication that the window is full
-Receipt of an ACK: In our GBN protocol an acknowledgement for a packet with
sequence number n will be taken to be a cumulative acknowledgement
-A timeout event: The protocol’s name “Go-Back-N” is derived from the senders
behaviour in the presence of lost or delayed packets, as in the stop and wait protocol a
timer will again be used to recover from lost data or acknowledgement packets, if a
timeout occurs the sender resends all packets that have been previously sent but not yet
acknowledged
 Receiver’s actions in GBN are simple, if a packet with a sequence number n is received
correctly and is in order, the receiver sends an ACK for packet n and delivers the data
portion of the packet to the upper layer, in all other cases the receiver discards the packet
and resends an ACK for the most recently received in order packet
 Since packets are delivered one at a time, if packet k is delivered and acknowledged then
all packets with a sequence number lower than k have been delivered
 Suppose that packet n is expected but packet n+1 arrives, because data must be delivered
in order the receiver could buffer (save) packet n+1 and then deliver this packet to the
upper layer after receiving packet n
  However if packet n is lost, both it and packet n+1 will be retransmitted as a result of the
retransmission rule at the sender
 Therefore the receiver can simply discard packet n+1
 Advantage of this approach is simplicity of receiver buffering, the receiver need not
buffer any out of order packets
 While the sender must maintain the upper and lower bounds of its window and its
position of nextseqnum, the only piece of information the receiver must maintain is the
sequence number of the next in order packet
 The disadvantage of throwing away a correctly received packet is that the subsequent
retransmission may be lost or garbled and more retransmissions would be required
 The implementation would be in the form of various procedures that implement the
actions to be taken in response to the various events that occur
 In event-based programming the various procedures are called either by other procedures
in the protocol stack or as the result of an interrupt
 In the sender, these events would be:
-Call from upper layer entity to invoke rdt_send()
-A timer interrupt
-A call from the lower layer to invoke rdt_rcv() when a packet arrives

Selective Repeat(SR):
 The GBN protocol allows the sender to fill the pipeline with packets, thus avoiding
channel utilization problems we noted in the stop and wait protocols
 GBN itself suffers from performance problems, in particular when the window size and
bandwidth delay product are both large, many packets can be in the pipeline
 A single packet error can thus cause GBN to retransmit a large number of packets
unnecessarily
 As the probability of channel errors increases, the pipeline can become filled with these
unnecessary transmissions
 Selective repeat protocols avoid unnecessary retransmissions by having the sender
retransmit only those packets that it suspects were received in error (that is, were lost or
corrupted) at the receiver
 A window size of N will again be used to limit the number of outstanding
unacknowledged packets in the pipeline
 However unlike GBN, the sender will have already received ACKs for some of the
packets in the window
 The SR receiver will acknowledge a correctly received packet whether it is in order or
not
 Out of order packets are buffered until any missing packets (that is packets with lower
sequence numbers) are received at which point a batch of packets are delivered to the
upper layer


 In step 2 figure 3.25 the receiver acknowledges the already received packets with certain
sequence numbers below the current window base
  When the “channel” connecting the two is a network, packet reordering can occur
 One manifestation of packet reordering is that old copies of a packet with a sequence or
acknowledgement number of x can appear, even though neither the sender’s nor
receiver’s window contains x
 Because sequence numbers may be reused, some care must be taken to guard against
such duplicate packets
 The approach taken in practice is to ensure that a sequence number is not reused until the
sender is “sure” that any previously sent packets with sequence number x are no longer in
the network
 This is done by assuming that a packet cannot “live” in the network for longer than some
fixed maximum amount of time
 A maximum packet lifetime of approx 3 minutes is assumed in the TCP extensions high
speed networks

TCP connection:
 TCP is said to be connection-oriented because before one application process can begin
to send data, the two processes must first “handshake” that is they must send some
preliminary segments to eachother to establish the parameters of the ensuing data transfer
 The TCP connection is an not end-to-end, TDM or FDM circuit as in a circuit-switched
network
 Instead the connection is a logical one with common state residing only in the TCPs in
the two communicating end systems
 Recall that because the TCP protocol only runs in the end systems and not intermediate
network elements (routers and link layer switches) the intermediate network elements do
not maintain TCP connection state
 A TCP connection provides a full-duplex service: If there is a TCP connection between
process A on one host and process B on another host, then the application layer data can
flow from process A to process B at the same time as application layer data flows from
process B to process A
 A TCP connection is always point-to-point, between a single sender and single receiver
 Recall that the process that is initiating the connection is called the client process while
the other is called the server process
 The client application process first informs the client transport layer that it wants to
establish connection to a process in the server
 TCP in the client then proceeds to establish a TCP connection with TCP in the server
 Client first sends a special TCP segment; the server responds with a second special TCP
segment; finally the client responds again with a third special segment
 The first two special segments carry no payload (no application layer data), the third of
these segments may carry a payload
 Because three segments are sent between the two hosts, this connection establishment
procedure is often referred to as a “three-way handshake”
 Once a TCP connection is established, the two application processes can send data to
eachother
 The client process passes a stream of data through the socket
 TCP directs this data to the connections send buffer which is one of the buffers that is set
aside during the initial three way handshake
 From time to time TCP will grab chunks of data from the send buffer and pass the data to
the network layer
 The maximum amount of data that can be grabbed and placed in a segment is limited by
the maximum segment size (MSS)
 The MSS is typically set by first determining the length of the largest link-layer frame
that can be sent by the local sending host (the so called maximum transmission unit
(MTU))
 Typical value of MSS = 1460 bytes
 The MSS is the maximum amount of application layer data in the segment, not the
maximum size of the TCP segment including headers
 TCP pairs each chunk of client data with a TCP header thereby forming TCP segments
 Segments are passed down to the network layer where they are separately encapsulated
within the network layer IP datagrams
 The datagrams are sent into the network
  When TCP receives a segment at the other end the segments data is placed in the TCP
connection receive buffer
 The application reads the stream of data from this buffer
 TCP connection consists of buffers, variables and a socket connection a process in one
host and another set of buffers, variables and a socket connection to a process in another
host

TCP segment structure:

 The TCP segment consists of header fields and a data field
 The data field contains a chunk of application data
 The MSS limits the max size of the segment’s data field
 TCP header is typically 20 bytes (12 bites more than UDP header)
 The header includes source and destination port numbers
 The header includes a checksum field
 The 32 bit sequence number field and 32 bit acknowledgement number field
 The 16 bit receive window field is used for flow control
 The 4 bit header length field specifies the length of the TCP header in 32 bits
 The optional and variable length options field is used when a sender and receiver
negotiate the maximum segment size (MSS) or as a window scaling factor for use in high
speed networks, a Time-Stamping option is also defined
 The flag field contains 6 bits, the ACK bit is used to indicate that the value carried in the
acknowledgement field is valid
 The RST, SYN and FIN bits are used for connection setup and teardown
 The CWR and ECE bits are used in explicit congestion notification
 Setting the PSH bit indicates that the receiver should pass the data to the upper layer
immediately
 Finally the URG bit is used to indicate that there is data in this segment that the sending
side upper layer entity has marked as urgent
 The location of the last byte of this urgent data is indicated by the 16 bit urgent data
pointer field

 Two of the most important fields in the TCP segment header are the sequence number
field and the acknowledgement number field
 TCP views data as an unstructured but ordered stream of bytes
 TCP’s use of sequence numbers reflects his view in that the sequence numbers are over
the stream of transmitted bytes and not over the series of transmitted segments
 The sequence number for a segment is therefore the byte stream number of the first byte
in the segment
 The TCP in host A will implicitly number each byte in the data stream
 TCP constructs segments out of the data stream, the first segments gets assigned
sequence number 0
 Each sequence number is inserted in the sequence umber field in the header of the
appropriate TCP segment
 Recall that TCP is full-duplex so that host A may be receiving data from Host B while it
sends data to host B (as part of the same connection)
 Each of the segments that arrive from host B has a sequence number for the data flowing
from B to A
 The acknowledgement number that host A puts in its segment is the sequence number of
the next byte Host A is expecting from host B
 Because TCP only acknowledges bytes up to the first missing byte in the stream, TCP is
said to provide cumulative acknowledgements
 What does a host do when it receives out of order segments in a TCP connection?:
1. The receiver immediately discards out of order segments
2. Or the receiver keeps the out of order bytes and waits for the missing bytes to fill the
gaps
 Both sides of a TCP connection randomly choose an initial sequence number
 This is done to minimize the possibility that a segment that is still present in the network
from an earlier, already terminated connection is mistaken for a valid segment in a later
connection between two of the same hosts
 Sequence number of a segment is the sequence number of the first byte in the data field
 Acknowledgement number is the sequence number of the next byte of data that the host
is waiting for

 The first segment is sent from the client to the server

 The second segment is sent from the server to the client to serve a dual purpose of
providing an acknowledgement that data was received and to echo back the message
 Acknowledgement for client to server data is carried in a segment carrying server to
client data, this acknowledgement is said to be piggybacked on the server to client data
segment
 The third segment is sent from the client to the server to acknowledge the data it has
received from the server
 This segment has an empty data field
 But because TCP has a sequence number data field the segment needs to have some
sequence number
Round trip time estimation and timeout
 TCP uses a timeout/retransmit mechanism to recover from lost segments
 The timeout should be larger than the connections round trip time (RTT) (the time from
when a segment is sent until it is acknowledged)
 The sample RTT for a segment is the amount of time between when the segment is sent
(passed to IP) and when acknowledgement is received
 Most TCP implementations take only one SampleRTT measurement at a time
 The sampleRTT is being estimated for only one of the transmitted but currently
acknowledged segments, leading to a new value of sampleRTT approximately once every
RTT
 TCP never computes a sampleRTT for a segment that has been retransmitted; it only
measures SampleRTT for segments that have been transmitted once
 The sampleRTT values will fluctuate from segment to segment due to congestion in the
routers and t othe varying load on the end systems,
 It is therefore natural to take some sort of average sampleRTT values
 TCP maintains an average (called estimatedRTT) of the SampleRTT values
 The new value of estimatedRTT is a weighted combination of the previous estimatedRTT
and the new value for SampleRTT
 EstimatedRTT is a weighted average of the smapleRTT values
 This weighted average puts more weight on recent samples than on old samples
 This is natural as the more recent samples better reflect the current congestion in the
network
 This type of average is called an exponential weighted moving average (EWMA)
 In addition to having an estimate of the RTT, it is also valuable to have a measure of the
variability of the RTT
 DevRTT as an estimate of how much sampleRTT deviates from EstimatedRTT
 DevRTT is an EWMA of the difference between sampleRTT and estimatedRTT
 If the sampleRTT values have little fluctuation then DevRTT will be small
 TCO’s timeout interval should be greater than or equal to EstimatedRTT or unnecessary
retransmissions would be sent
 Timeout interval should not be too much larger than EstimatedRTT or else when a
segment is lost TCP would not quickly retransmit the segment leading to large data
transfer delays
 It is therefore desirable to set the timeout equal to the EstimatedRTT plus some margin
 An initial TimeoutInterval of 1 second is recommended
 Also when a timeout occurs the value of timeoutInterval is doubled to avoid premature
timeout occurring for subsequent segment that will soon be acknowledged
 However as soon as a segment is received and estimatedRTT is updated, the
timeoutInterval is computed again
Reliable Data Transfer
 Internet network-layer service is unreliable
 IP does not guarantee datagram delivery or in order delivery or integrity of data
 Datagrams can overflow router buffers and never reach their destination
 Because transport layer segments are carried caross the network by IP datagrams,
segments suffer these problems as well
 TCP creates a reliable data transport service on top of IPs unreliable best effort service
 TCPs RDT service ensures that the data stream that a process reads out of its TCP receive
buffer is uncorrupted, without gaps or duplication and in sequence (the byte stream is
exactly the way it was when it was sent)
 TCP timer management procedures use only a single retransmission timer, even if there
are multiple transmitted but not acknowledged segments
 TCP provides RDT in two incremental steps:
-Highly simplified description of a TCP sender that uses only timeouts to recover from
lost segments, we then present a more complete description that uses duplicate
acknowledgements in addition to timeouts
 There are three major events related to data transmission and retransmission in the TCP
sender:
-Data received from application above
-Timer timeout
-ACK receipt
 TCP receives data from the application, encapsulates the data in a segment and passes the
segment to IP
 If the timer is already not running for some other segment, TCP starts the timer when the
segment is passed to IP
 The expiration interval for this timer is the TimeoutInterval which is calculated from
EstimatedRTT and DevRTT
 Second major event is the timeout, TCP responds to the timeout event by retransmitting
the segment that caused the timeout, TCP then restarts the timer

Flow Control:
 If the application is relatively slow at reading data, the sender can very easily overflow
the connection’s receive buffer
 TCP provides a flow control service to eliminate the possibility of the sender overflowing
the receiver’s buffer
 Flow control is a speed matching service, matching the rate at which the sender is
sending against the reading rate of the receiving application
 TCP provides flow control by having the sender maintain a variable called the receive
window
  This is used to give the sender an idea of how much free buffer space is available at the
receiver
 Due to TCP being full-duplex, the sender at each side maintains a distinct receive
window
 Receive window (rwnd) is set to the amount of spare room in buffer
 Rwnd is dynamic

There is one minor technical problem with this scheme. To see this, suppose Host B’s receive
buffer becomes full so that rwnd = 0. After advertising rwnd = 0 to Host A, also suppose that B
has nothing to send to A. Now consider what happens. As the application process at B empties
the buffer, TCP does not send new segments with new rwnd values to Host A

To counter this TCP specification requires Host A to continue to send segments with one data
byte when B’s receive window is zero.

TCP connection management:

The client application process first informs the client TCP that it wants to establish a connection
to a process in the server
TCP in the client then proceeds to establish connection with TCP in server in the following way:

1. Client side TCP first sends a special TCP segment to the server side TCP, this contains
no data but one of the flag bits in the segment’s header, the SYN bit is set to 1, client
randomly chooses an initial sequence number, this segment is encapsulated within an ip
datagram and sent to the server
2. Once the datagram arrives containing the TCP SYN segment, the server extracts the TCP
SYN segment, allocates the TCP buffers and variables to the connection and sends a
connection granted segment to client TCP, This connection granted segment also contains
no data but does contain the SYN bit set to 1, the acknowledgement field is set to
client_isn+1 and the server chooses its own random initial sequence number (this is a
synack segment)
3. Upon receiving SYNACK segment, the client allocates buffers and variables to
connection and sends the server another segment acknowledging the connection granted
segment (done via the value: server_isn+1) in the acknowledgement field of the TCP
segment header

 Once this is done the client and server hosts can send eachother data, in each of these
future segments being sent SYN will be set to 0
 Either participants can end the connection, when a connection ends the resources (buffers
and variables) in the hosts are deallocated
 

Client application process issues a close command, this causes the client TCP to send a special
TCP segment to server process with flag bit in segment header for FIN bit being set to 1

Once the server receives this is sends the client an acknowledgement segment in return

The server then sends its own shutdown segment which has the FIN bit set to 1, client
acknowledges shutdown segment
Established state = data sending state