week4 lec1-bscs1

Chapter 3Transport Layer

Computer Networking: A Top Down Approach, 4th edition. Jim Kurose, Keith RossAddison-Wesley

Chapter 3: Transport LayerOur goals: Understand principles

behind transport layer services: Multiplexing/De-multiplexing Reliable data transfer Congestion control Flow Control

Learn about transport layer protocols in the Internet: UDP: connectionless

transport TCP: connection-oriented

transport TCP Reliability TCP congestion control TCP Flow Control

Transport Services and Protocols Transport layer protocols provide

logical communication between app processes running on different hosts From application’s perspective

as if the host running the process are directly connected

Transport protocols run in end systems Not in routers Sender side: Breaks app

messages into segments, passes to network layer

Receiver side: Reassembles segments into messages, passes to application layer

More than one transport protocol available to applications Internet: TCP and UDP

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

logical end-end transport

Transport vs. Network layer

Network layer: logical communication between hosts

Transport layer: logical communication between processes

Household Analogy:

12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill network-layer protocol = postal service

Transport layer relies on Network layer

Internet Transport Layer Protocols Internet Protocol (IP)

Best effort delivery service No guarantees for segment delivery No guarantees for orderly delivery of data IP is unreliable service

Extending Host-to-Host delivery to process-to-process delivery. Transport layer Multiplexing and De-multiplexing

UDP and TCP also provide integrity checking by including error detection field in their segment headers.

UDP services Process to process data delivery Error checking

TCP Reliable data Transfer Congestion Control, sequence numbers,

acknowledgements and timers

Multiplexing/De-Multiplexing

Every process has a socket which allows Data to pass from the network to the process Data to pass from the process to the network

Receiving host directs an incoming transport layer segment to appropriate socket. Uses set of fields in the transport layer segments

Delivering data in the transport layer segment to the correct socket is called de-multiplexing.

Gathering data chunks at the source host from different sockets ,appending header information and passing to the network layer is called multiplexing

Household analogy

Multiplexing/De-multiplexing

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4P1

host 1 host 2 host 3

= process= socket

delivering received segmentsto correct socket

Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)

Multiplexing at send host:

How De-multiplexing works

Sockets have unique identifier

Each segment has special field that indicate the socket to which the segment is to be delivered Source port number Destination port number Port is a 16 bit number

0 to 655350 to 1023 are well

known port numbers and are reserved

Source Port # Dest Port #

32 bits

Application Data (message)

Other Header Fields

Transport Layer Segment Format

Connectionless Transport:UDP

Internet transport protocol RFC 768 UDP does just about as little as a transport layer protocol

can do Multiplexing/De-multiplexing Error checking “Best Effort” service, UDP segments may be:

lost delivered out of order to applications

Connectionless: No handshaking between UDP sender, receiver Each UDP segment handled independently of others

Connectionless Transport:UDP

Why is there a UDP? No connection establishment

TCP uses a three way handshake UDP has no delay to establish a connection

DNS uses UDP No connection state at sender, receiver

TCP maintains connection state Congestion control parameters, sequence numbers etc.

UDP maintains no connection state Server can support many more active clients with UDP than over

TCP Small segment header

20 bytes of header in TCP Only 8 bytes of header in UDP

No congestion control UDP can blast away as fast as desired

UDP: Segment Structure

The application data occupies the data field of the UDP segment.

UDP header has four fields Each of two bytes

Checksum Used by receiving

host to check for errors in the segment

Length Length of the UDP

segment

source port # dest port #

Application data (message)

UDP segment format

length checksum

Length, inbytes of

UDPsegment,including

header

Connectionless (UDP) De-multiplexing

ClientIP:B

P2

client IP: A

P1P1P3

serverIP: C

SP: 6428DP: 9157

SP: 9157DP: 6428

SP: 6428

DP: 5775

SP: 5775DP: 6428

SP provides “return address”

UDP Checksum

Sender: Treat segment contents

as sequence of 16-bit word

Checksum: 1’s complement of the sum of all the 16-bit words.

Sender puts checksum value into UDP checksum field

Receiver: All segments are added

and than sum is added with sender's checksum.

If no errors are introduced into the packet, then clearly the sum at the receiver will be all 1’s.

If receiver side checksum contains any 0 then, error is detected and the packet is discarded.

Checksum is used to determine whether bits within the UDP segment have been altered e.g. noise in the link.

Checksum Example (16 bits segment) 0110011001100110

0101010101010101 0000111100001111

The sum of first of these 16-bits integer is: 0110011001100110 0101010101010101 1011101110111011Adding the third one to the above sum gives 1011101110111011 0000111100001111 1100101011001010 (sum of all

segments)The checksum at sender side is : 0011010100110101 (1’s

complement). Now at the receiver side, again all segments are added

and sum is added with sender's checksum. If no error than check of receiver would be :

1111111111111111

Checksum Example Note

When adding numbers, a carryout from the most significant bit needs to be added to the result

Example: Add two 16-bit words

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

sumchecksum

Difference between UDP and UDP Lite?

Home Assignment

Principles of Reliable Data Transfer• Important in application, transport, link layers• Top-10 list of important networking topics!

Principles of Reliable Data Transfer (rdt)• Important in application, transport, link layers• Top-10 list of important networking topics!

Principles of Reliable Data Transfer• Important in application, transport, link layers• Top-10 list of important networking topics!

Reliable Data Transfer: Getting Started

sendside

receiveside

rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer

udt_send(): called by rdt protocol, to transfer packet over unreliable channel to receiver

rdt_rcv(): called when packet arrives on rcv-side of channel

deliver_data(): called by rdt to deliver data to upper layer

Reliable Data Transfer: Getting Started

We’ll:• Incrementally develop sender, receiver sides of

reliable data transfer protocol (rdt)• Consider only unidirectional data transfer

– but control info will flow on both directions!

• Use Finite State Machines (FSM) to specify sender, receiver

state 1

state 2

event causing state transitionactions taken on state transition

state: When in this “state” next state uniquely determined by next

event

eventactions

Rdt1.0: Reliable Data Transfer over a Perfectly Reliable Channel

• Underlying channel perfectly reliable– no bit errors– no loss of packets

• Separate FSMs for sender, receiver:– sender sends data into underlying channel– receiver read data from underlying channel

• The initial state of the FSM is indicated by the dashed line

Wait for call from above packet =make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packet,data)deliver_data(data)

rdt_rcv(packet)

Sender Receiver

Wait for call from below

Note:Perfectly reliable channel no need for feedback

Rdt2.0: Channel with Bit Errors• More realistic model

– Underlying channel may flip bits in packet

• How people deal with such a situation– OK (positive acknowledgment)– Please repeat that (negative acknowledgements)– Acknowledgements (ACKs): Receiver explicitly tells sender that pkt

received OK– Negative acknowledgements (NAKs): Receiver explicitly tells sender

that pkt had errors– Sender retransmits pkt on receipt of NAK

• These control messages let the receiver know– What has been received in error and requires repetition

• Automatic Repeat reQuest (ARQ) protocols.

Rdt2.0: Channel with Bit Errors

Three capabilities are required in ARQ to handle the presence of bit errors.

• Error Detection:

– Needed to allow the receiver to detect bit errors– Checksum field in the header

• Receiver Feed Back

– Receiver provided explicit feedback– ACK– NAK

• Retransmission

– A packet that is received in error will be retransmitted• New mechanisms in rdt2.0 (beyond rdt1.0):

– Error detection– Receiver feedback: Control msgs (ACK,NAK) Rcvr->Sender

Rdt2.0: FSM Specification

Wait for call from above

snkpkt = make_pkt(data, checksum) udt_send(sndpkt)

extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or NAK


sender

receiver

rdt_send(data)

L

Rdt2.0: Operation with No Errors


snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)



udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)Wait for

ACK or NAK


rdt_send(data)

L

Rdt2.0: error scenario


snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)


udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)Wait for

ACK or NAK


rdt_send(data)

L

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)


Rdt2.0• rdt2.0 is a stop and wait protocol

– Sender sends one packet, then waits for receiver response

• rdt2.0 has a fatal flaw• What happens if ACK/NAK get

corrupted?– Add checksum bits to

ACK/NAK• How the protocol should recover from

errors in ACK/NAK?– Retransmission on receipt of a corrupt

ACK/NAK– Retransmission causes duplicates– Receiver does not know whether ACK

or NAK it sent was received correctly– Receiver does not know a priori

whether an arriving packet contains new data or is a retransmission

Handling Duplicates: • Sender retransmits current

packet if ACK/NAK garbled• Sender adds sequence number

to each packet• Receiver discards (doesn’t

deliver up) duplicate packet

week4 lec1-bscs1

Education