UNIT –II Transport Layer Prof. Nalini Mhetre, Dept. of Computer Engg. SKNCOE, Pune

UNIT –IITransport Layer

Prof. Nalini Mhetre, Dept. of Computer Engg.

SKNCOE, Pune

2

Transport Layer

• Part 1 : TCP, UDP• Part 2 : Socket Programming• Part 3 : TCP Flow Control and Congestion Control• Part 4 : TCP in Wireless Network, Real Time Transport

Protocol• Part 5 : Stream Control Transmission Protocol• Part 6 : Quality of Service(QoS), Differentiated Services, Integrated Services

3

Transport Layer services and protocols

• Provide logical communication between app processes running on different hosts

• Transport protocols run in end systems – send side: breaks app messages into segments,

passes to network layer– rcv side: reassembles segments into messages,

passes to app layer

• More than one transport protocol available to apps– Internet: TCP and UDP

applicationtransportnetworkdata linkphysical

logical end-end transport


4

Internet transport-layer protocols

• Reliable, in-order delivery (TCP)– congestion control – flow control– connection setup

• Unreliable, unordered delivery: UDP– no-frills extension of “best-effort” IP

• Services not available: – delay guarantees– bandwidth guarantees



networkdata linkphysical







logical end-end transport

5

Multiplexing/Demultiplexing

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:

6

How demultiplexing works

• Host receives IP datagrams– Each datagram has source IP address,

destination IP address– Each datagram carries 1 transport-layer

segment– Each segment has source, destination port

number

• host uses IP addresses & port numbers to direct segment to appropriate socket

source port # dest port #

32 bits

applicationdata (message)

other header fields

TCP/UDP segment format

14

UDP: User Datagram Protocol [RFC 768]

• “no frills,” “bare bones” Internet transport protocol

• “best effort” service, UDP segments may be:– lost– delivered out of order to app

• Connectionless:– No handshaking between UDP

sender, receiver– each UDP segment handled

independently of others

Why is there a UDP?

• no connection establishment (which can add delay)

• simple: no connection state at sender, receiver

• small segment header• no congestion control: UDP

can blast away as fast as desired

15

UDP: more

• often used for streaming multimedia apps– loss tolerant– rate sensitive

• other UDP uses– DNS– SNMP

• reliable transfer over UDP: add reliability at application layer– application-specific error recovery!


32 bits

ApplicationData (message)

UDP segment format

Length checksumLength, in

bytes of UDPsegment,including

header

16

UDP checksum

Sender:

• treat segment contents as sequence of 16-bit integers

• checksum: addition (1’s complement sum) of segment contents

• sender puts checksum value into UDP checksum field

Receiver:

• compute checksum of received segment

• check if computed checksum equals checksum field value:– NO - error detected– YES - no error detected. But maybe

errors nonetheless? More later ….

Goal: detect “errors” (e.g. flipped bits) in transmitted segment

17

Internet 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 integers

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

sum

checksum

18

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

• full duplex data:– bi-directional data flow in same connection– MSS: maximum segment size

• connection-oriented: – handshaking (exchange of control msgs) init’s

sender, receiver state before data exchange

• flow controlled:– sender will not overwhelm receiver

• point-to-point:– one sender, one receiver

• reliable, in-order byte steam:– no “message boundaries”

• pipelined:– TCP congestion and flow

control set window size

• send & receive buffers

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data

19

TCP segment structure


32 bits

applicationdata (variable length)

sequence numberacknowledgement number

Receive window

Urg data pnterchecksumFSRPAUhead

lennotused

Options (variable length)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

20

TCP seq. #’s and ACKs

Seq. #’s:– byte stream “number” of

first byte in segment’s data

ACKs:– seq # of next byte

expected from other side– cumulative ACK

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes‘C’

host ACKsreceipt of echoed‘C’

host ACKsreceipt of‘C’, echoesback ‘C’

timesimple telnet scenario

21

TCP Connection Management

Recall: TCP sender, receiver establish “connection” before exchanging data segments

• initialize TCP variables:– seq. #s– buffers, flow control info (e.g.

RcvWindow)

• client: connection initiator Socket clientSocket = new

Socket("hostname","port number");

• server: contacted by client Socket connectionSocket =

welcomeSocket.accept();

Three way handshake:

Step 1: client host sends TCP SYN segment to server

– specifies initial seq #– no data

Step 2: server host receives SYN, replies with SYNACK segment

– server allocates buffers– specifies server initial seq. #

Step 3: client receives SYNACK, replies with ACK segment, which may contain data

22

TCP Connection Management (cont.)

Closing a connection:

client closes socket:

clientSocket.close();

Step 1: client end system sends TCP FIN control segment to server

Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.

client

FIN

server

ACK

ACK

FIN

close

close

closedti

med

wai

t

23

TCP Connection Management (cont.)

Step 3: client receives FIN, replies with ACK. – Enters “timed wait” - will respond with

ACK to received FINs

Step 4: server, receives ACK. Connection closed.

Note: with small modification, can handle simultaneous FINs.

client

FIN

server

ACK

ACK

FIN

closing

closing

closedti

med

wai

t

closed

25

TCP reliable data transfer

• TCP creates rdt service on top of IP’s unreliable service

• Pipelined segments• Cumulative acks• TCP uses single

retransmission timer

• Retransmissions are triggered by:– timeout events– duplicate acks

• Initially consider simplified TCP sender:– ignore duplicate acks– ignore flow control, congestion

control

26

TCP sender events:

data rcvd from app:• Create segment with seq #• seq # is byte-stream number

of first data byte in segment• start timer if not already

running (think of timer as for oldest unacked segment)

• expiration interval: TimeOutInterval

timeout:• retransmit segment that caused

timeout• restart timer Ack rcvd:• If acknowledges previously

unacked segments– update what is known to be acked– start timer if there are

outstanding segments

TCP: retransmission scenarios

Host A

Seq=100, 20 bytes data

ACK=100

timepremature timeout

Host B


ACK=120


Seq

=92

tim

eou

t

ACK=120

Host ASeq=92, 8 bytes data

ACK=100

losstim

eou

t

lost ACK scenario

Host B

XSeq=92, 8 bytes data

ACK=100

timeS

eq=

92 t

imeo

ut

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

1

TCP retransmission scenarios (more)

Host ASeq=92, 8 bytes data

ACK=100

losstim

eou

t

Cumulative ACK scenario

Host B

X


ACK=120

time

SendBase= 120

•Doubling the timeout interval• Fast Retransmit

1

29

Achieving Reliability

• Reliable connection setup• Reliable data transmission• Reliable connection shutdown

30

Reliable Data Transmission

• Positive Acknowledgement– Receiver returns short message when data arrives– Call an acknowledgement

• Retransmission– Sender starts timer whenever message is transmitted– If timer expires before acknowledgement arrives, sender

retransmits message

31

Retransmission Illustrated

32

How Long Should TCP Wait Before Retransmitting?

• Time for acknowledgement to arrive depends on– Distance to destination– Current traffic conditions

• Multiple connections can be open simultaneously

• Traffic conditions change rapidly

33

Important Point

The delay required for data to reach a destination and an acknowledgement to return depends on traffic in the internet as well as the distance to the destination.

Since it allows multiple application programs to communicate with multiple destinations concurrently, TCP must handle a variety of delays that can change rapidly.

34

Solving the Retransmission Problem

• Keep estimate of round trip time on each connection

• Use current estimate to set retransmission timer

• Known as adaptive retransmission• Key to TCP’s success

35

Adaptive Retransmission Illustrated

• Timeout depends on current round-trip estimate

36

Transport Layer

• Part 1 : TCP, UDP• Part 3 : TCP Flow Control and Congestion Control• Part 2 : Socket Programming• Part 4 : TCP in Wireless Network, Real Time Transport


37

TCP Flow Control

• Receiver– Advertises available buffer space– Called the window

• Sender– Can send up to entire window before ACK arrives

• Also called a sliding window protocol

38

Window Advertisement

• Each acknowledgement carries new window information– Call window advertisement– Can be zero (called closed window)

• Interpretation: I have received up through X and can take Y more octets

39

Window Advertisement Illustrated

40

Another View: Sliding Window Illustrated

41

Byte Stream Sequencing

• Segments are labeled with a sequence number• Protects from out-of-order delivery• 32-bit number• Limited size of byte stream?• Initial Sequence Numbers (ISNs) must be exchanged

at TCP connection establishment

42

Pipelined protocols

pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts– range of sequence numbers must be

increased– buffering at sender and/or receiver

two generic forms of pipelined protocols: go-Back-N, selective repeat

43

Pipelining: increased utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

3-packet pipelining increases utilization by a factor of 3!

U sender =

.0024 30.008

= 0.00081 3L / R

RTT + L / R =

44

Pipelined protocols: overview

Go-back-N:• sender can have up to N

unacked packets in pipeline• receiver only sends

cumulative ack– Doesn’t ack packet if there’s

a gap• sender has timer for oldest

unacked packet– when timer expires,

retransmit all unacked packets

Selective Repeat:• sender can have up to N

unack’ed packets in pipeline• rcvr sends individual ack for

each packet

• sender maintains timer for each unacked packet– when timer expires, retransmit

only that unacked packet

45

Go-Back-N: sender

• k-bit seq # in pkt header• “window” of up to N, consecutive unack’ed pkts allowed

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver)

timer for oldest in-flight pkt timeout(n): retransmit packet n and all higher seq

# pkts in window

GBN in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1 receive pkt3, discard, (re)send ack1rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2send pkt3send pkt4send pkt5

Xloss

receive pkt4, discard, (re)send ack1receive pkt5, discard, (re)send ack1

rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5

ignore duplicate ACK

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

1

47

Selective repeat

• receiver individually acknowledges all correctly received pkts– buffers pkts, as needed, for eventual in-order

delivery to upper layer• sender only resends pkts for which ACK

not received– sender timer for each unACKed pkt

• sender window– N consecutive seq #’s– limits seq #s of sent, unACKed pkts

Selective repeat: sender, receiver windows

1

49

Selective repeat

data from above: if next available seq # in

window, send pkt

timeout(n): resend pkt n, restart timer

ACK(n) in [sendbase,sendbase+N]:

mark pkt n as received if n smallest unACKed pkt,

advance window base to next unACKed seq #

senderpkt n in [rcvbase,

rcvbase+N-1] send ACK(n) out-of-order: buffer in-order: deliver (also

deliver buffered, in-order pkts), advance window to next not-yet-received pkt

pkt n in [rcvbase-N,rcvbase-1]

ACK(n)otherwise: ignore

receiver

Selective repeat in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1 receive pkt3, buffer, send ack3rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2

Xloss

receive pkt4, buffer, send ack4receive pkt5, buffer, send ack5

rcv pkt2; deliver pkt2,pkt3, pkt4, pkt5; send ack2

record ack3 arrived

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

record ack4 arrived

record ack4 arrived

Q: what happens when ack2 arrives? 1

51

Transport Layer

• Part 1 : TCP, UDP• Part 3 : TCP Flow Control and Congestion Control• Part 2 : Socket Programming• Part 4 : TCP in Wireless Network, Real Time Transport


52

Protocol Ports

• Each application assigned a unique integer• Server

– Follows standard– Always uses same port number– Usually uses lower port numbers

• Client– Obtains unused port from protocol software– Usually uses higher port numbers

53

Protocol Port Example

• Web server application is assigned port 80• Web client application obtains port 32938• TCP segment sent from client to server has

– source port number 32938– destination port number 80

• When web server responds, TCP segment has– source port number 80– destination port number 32938

54

Standard Protocol Ports

• See http://www.iana.org for standard protocol port assignments• See /etc/services in UNIX systems and \winnt\system32\drivers\etc\services in Windows NT

55

IP addresses versus port numbers

56

• In the Internet model ,the port no. are 16 bit integers between 0 to 65,535.

Figure Port numbers

57

Assigned & controlled by IANA

Not assigned & controlled by IANAThey can only be registered with IANA to prevent duplication.

Neither controlled nor registered. They can be used by any process .

Figure IANA ranges

58

Figure Socket address

59

The interface that the OS provides to its networking subsystem

application layer

transport layer (TCP/UDP)

network layer (IP)

link layer (e.g. ethernet)

physical layer

application layer

transport layer (TCP/UDP)

network layer (IP)

link layer (e.g. ethernet)

physical layer

OS network

stack

Sockets as means for inter-process communication (IPC)

Client Process Server Process

SocketOS network

stack

Socket

Internet

Internet

Internet

60

Internet Connections (TCP/IP)

Connection socket pair(128.2.194.242:3479, 208.216.181.15:80)

Server(port 80)

Client

Client socket address128.2.194.242:3479

Server socket address

208.216.181.15:80

Client host address128.2.194.242

Server host address208.216.181.15

• Address the machine on the network– By IP address

• Address the process– By the “port”-number

• The pair of IP-address + port – makes up a “socket-address”

Note: 3479 is anephemeral port allocated

by the kernel

Note: 80 is a well-known portassociated with Web servers

61

Clients

• Examples of client programs– Web browsers, ftp, telnet, ssh

• How does a client find the server?– The IP address in the server socket address identifies the host– The (well-known) port in the server socket address identifies the

service, and thus implicitly identifies the server process that performs that service.

– Examples of well known ports• Port 7: Echo server• Port 23: Telnet server• Port 25: Mail server• Port 80: Web server

62

Using Ports to Identify Services

Web server(port 80)

Client host

Server host 128.2.194.242

Echo server(port 7)

Service request for128.2.194.242:80

(i.e., the Web server)

Web server(port 80)

Echo server(port 7)

Service request for128.2.194.242:7

(i.e., the echo server)

Kernel

Kernel

Client

Client

63

Servers

• Servers are long-running processes (daemons).– Created at boot-time (typically) by the init process (process 1)– Run continuously until the machine is turned off.

• Each server waits for requests to arrive on a well-known port associated with a particular service.– Port 7: echo server– Port 23: telnet server– Port 25: mail server– Port 80: HTTP server

• Other applications should choose between 1024 and 65535

See /etc/services for a comprehensive list of the services available on a Linux machine.

64

Sockets

• What is a socket?– To the kernel, a socket is an endpoint of communication.– To an application, a socket is a file descriptor that lets the application

read/write from/to the network.• Remember: All Unix I/O devices, including networks, are modeled as files.

• Clients and servers communicate with each by reading from and writing to socket descriptors.

• The main distinction between regular file I/O and socket I/O is how the application “opens” the socket descriptors.

65

Figure 24.5 Socket structure

66

Figure 24.6 Socket types

67

Client+server: connectionless

CREATE

BIND

SEND

SEND

CLOSE

RECEIVE

68

Client+server: connection-oriented

Concurrent server

SOCKETBIND

LISTEN

CONNECT

ACCEPT

RECEIVE

RECEIVE

SEND

SEND

CLOSE

TCP three-way handshake

69

socket()

bind()

listen()

read()

close()

socket()

connect()

read()

write()

close()

blocks until server receivesa connect request from client

data

data

Server

Client

accept()

write()

connect negotiation

TCP socket calls

70

socket()

bind()

sendto()

close()

socket()

bind()

recvfrom()

sendto()

close()

blocks until server

receives data from clientdata

data

Server

Client

recvfrom()

UDP socket calls

71

System Calls for Elementary TCP Sockets

#include <sys/types.h>#include <sys/socket.h>

family: specifies the protocol family {AF_INET for TCP/IP}type: indicates communications semantics SOCK_STREAM stream socket TCP SOCK_DGRAM datagram socket UDP SOCK_RAW raw socket

protocol: set to 0 except for raw socketsreturns on success: socket descriptor {a small nonnegative integer} on error: -1Example:If (( sockfd = socket (AF_INET, SOCK_STREAM, 0)) < 0) err_sys (“socket call error”);

socket Function int socket ( int family, int type, int protocol );

72

sockfd: a socket descriptor returned by the socket function*servaddr: a pointer to a socket address structureaddrlen: the size of the socket address structure

The socket address structure must contain the IP address and the port number for the connection wanted.

In TCP connect initiates a three-way handshake. connect returns when the connection is established or when an error occurs.

returns on success: 0 on error: -1Example: if ( connect (sockfd, (struct sockaddr *) &servaddr, sizeof (servaddr)) != 0) err_sys(“connect call error”);

connect Function int connect (int sockfd, const struct sockaddr *servaddr, socklen_t addrlen);

73

bind assigns a local protocol address to a socket.protocol address: a 32 bit IPv4 address + a 16 bit TCP or UDP port

number.sockfd: a socket descriptor returned by the socket function.*myaddr: a pointer to a protocol-specific address.addrlen: the size of the socket address structure.Servers bind their “well-known port” when they start.returns on success: 0 on error: -1Example:If (bind (sd, (struct sockaddr *) &servaddr, sizeof (servaddr)) != 0) errsys (“bind call error”);

bind Function int bind (int sockfd, const struct sockaddr *myaddr, socklen_t addrlen);

74

Listen is called only by a TCP server and performs two actions:1. Converts an unconnected socket into a passive socket.2. Specifies the maximum number of connections that the

kernel should queue for this socket.returns on success: 0 on error: -1Example:If (listen (sd, 2) != 0) errsys (“listen call error”);

listen Function

int listen (int sockfd, int backlog);

75

accept is called by the TCP server to return the next completed connection from the front of the completed connection queue.

sockfd: this is the same socket descriptor as in listen call.

*cliaddr: used to return the protocol address of the connected peer process (i,e., the client process).

*addrlen: {this is a value-result argument}before the accept call: we set the integer value pointed to by *addrlen to the size of the socket address structure pointed to by cliaddr;on return from accept call: this integer value contains the actual number of bytes stored in the socket address structure.

returns on success: a new socket descriptor, on error: -1

accept Function int accept (int sockfd, struct sockaddr *cliaddr, socklen_t *addrlen);

76

For accept the first argument sockfd is the listening socketand the returned value is the connected socket.

The server will have one connected socket for each client connection accepted.

When the server is finished with a client, the connected socket must be closed.

Example: sfd = accept (s, NULL, NULL); if (sfd == -1) err_sys (“accept error”);

accept Function (cont.) int accept (int sockfd, struct sockaddr *cliaddr, socklen_t addrlen);

77

close marks the socket as closed and returns to the process immediately.

sockfd this socket descriptor is no longer useable.Note – TCP will try to send any data already queued to the

other end before the normal connection termination sequence.

Returns on success: 0 on error: -1Example:

close (s);

close Function

int close (int sockfd);

78

Socket primitives

• SOCKET: int socket(int domain, int type, int protocol);– domain := AF_INET (IPv4 protocol) – type := (SOCK_DGRAM or SOCK_STREAM )– protocol := 0 (IPPROTO_UDP or IPPROTO_TCP)– returned: socket descriptor (sockfd), -1 is an error

• BIND: int bind(int sockfd, struct sockaddr *my_addr, int addrlen);– sockfd - socket descriptor (returned from socket())– my_addr: socket address, struct sockaddr_in is used– addrlen := sizeof(struct sockaddr)

struct sockaddr_in { unsigned short sin_family; /* address family (always AF_INET) */ unsigned short sin_port; /* port num in network byte order */ struct in_addr sin_addr; /* IP addr in network byte order */ unsigned char sin_zero[8]; /* pad to sizeof(struct sockaddr) */ };

79

• LISTEN: int listen(int sockfd, int backlog); – backlog: how many connections we want to queue

• ACCEPT: int accept(int sockfd, void *addr, int *addrlen);– addr: here the socket-address of the caller will be written– returned: a new socket descriptor (for the temporal socket)

• CONNECT: int connect(int sockfd, struct sockaddr *serv_addr, int addrlen); //used by TCP client– parameters are same as for bind()

• SEND: int send(int sockfd, const void *msg, int len, int flags);– msg: message you want to send– len: length of the message– flags := 0– returned: the number of bytes actually sent

• RECEIVE: int recv(int sockfd, void *buf, int len, unsigned int flags);– buf: buffer to receive the message– len: length of the buffer (“don’t give me more!”)– flags := 0– returned: the number of bytes received

80

• SEND (DGRAM-style): int sendto(int sockfd, const void *msg, int len, int flags, const struct sockaddr *to, int tolen);– msg: message you want to send– len: length of the message– flags := 0– to: socket address of the remote process– tolen: = sizeof(struct sockaddr)– returned: the number of bytes actually sent

• RECEIVE (DGRAM-style): int recvfrom(int sockfd, void *buf, int len, unsigned int flags, struct sockaddr *from, int *fromlen);– buf: buffer to receive the message– len: length of the buffer (“don’t give me more!”)– from: socket address of the process that sent the data– fromlen:= sizeof(struct sockaddr)– flags := 0– returned: the number of bytes received

• CLOSE: close (socketfd);

81

Example programs in ‘C’

• On next slides 2 sample ‘C’ programs are given explaining socket primitives/system calls:

• 1st is echo client program• 2nd is echo server program

82

EchoClient.c – #include’s

#include <stdio.h> /* for printf() and fprintf() */#include <sys/socket.h> /* for socket(), connect(), sendto(), and recvfrom() */#include <arpa/inet.h> /* for sockaddr_in and

inet_addr() */#include <stdlib.h> /* for atoi() and exit() */#include <string.h> /* for memset() */#include <unistd.h> /* for close() */

#define ECHOMAX 255 /* Longest string to echo */

83

EchoClient.c -variable declarations

int main(int argc, char *argv[]){ int sock; /* Socket descriptor */ struct sockaddr_in echoServAddr; /* Echo server address */ struct sockaddr_in fromAddr; /* Source address of echo */ unsigned short echoServPort =7; /* Echo server port */ unsigned int fromSize; /* address size for recvfrom() */ char *servIP=“172.24.23.4”; /* IP address of server */ char *echoString=“I hope this works”; /* String to send to echo

server */ char echoBuffer[ECHOMAX+1]; /* Buffer for receiving echoed string */ int echoStringLen; /* Length of string to echo */ int respStringLen; /* Length of received response */

84

EchoClient.c … - creating the socket and sending

/* Create a datagram/UDP socket */ sock = socket(AF_INET, SOCK_DGRAM, 0);

/* Construct the server address structure */ memset(&echoServAddr, 0, sizeof(echoServAddr)); /* Zero out structure */ echoServAddr.sin_family = AF_INET; /* Internet addr family */ echoServAddr.sin_addr.s_addr = htonl(servIP); /* Server IP address */ echoServAddr.sin_port = htons(echoServPort); /* Server port */

/* Send the string to the server */ sendto(sock, echoString, echoStringLen, 0, (struct sockaddr *)

&echoServAddr, sizeof(echoServAddr);/* Recv a response */

85

EchoClient.c… – receiving and printing

fromSize = sizeof(fromAddr); recvfrom(sock, echoBuffer, ECHOMAX, 0, (struct sockaddr *) &fromAddr,

&fromSize); /* Error checks like packet is received from the same server*/

/* null-terminate the received data */ echoBuffer[echoStringLen] = '\0'; printf("Received: %s\n", echoBuffer); /* Print the echoed arg */close(sock); exit(0);} /* end of main () */

86

EchoServer.c

int main(int argc, char *argv[]){ int sock; /* Socket */ struct sockaddr_in echoServAddr; /* Local address */ struct sockaddr_in echoClntAddr; /* Client address */ unsigned int cliAddrLen; /* Length of incoming message */ char echoBuffer[ECHOMAX]; /* Buffer for echo string */ unsigned short echoServPort =7; /* Server port */ int recvMsgSize; /* Size of received message */ /* Create socket for sending/receiving datagrams */ sock = socket(AF_INET, SOCK_DGRAM, 0); /* Construct local address structure */ memset(&echoServAddr, 0, sizeof(echoServAddr)); /* Zero out structure */ echoServAddr.sin_family = AF_INET; /* Internet address family */ echoServAddr.sin_addr.s_addr = htonl(“172.24.23.4”); echoServAddr.sin_port = htons(echoServPort); /* Local port */

/* Bind to the local address */ bind(sock, (struct sockaddr *) &echoServAddr, sizeof(echoServAddr);

87

for (;;) /* Run forever */ { cliAddrLen = sizeof(echoClntAddr);

/* Block until receive message from a client */ recvMsgSize = recvfrom(sock, echoBuffer, ECHOMAX, 0, (struct sockaddr *) &echoClntAddr, &cliAddrLen);

printf("Handling client %s\n", inet_ntoa(echoClntAddr.sin_addr));

/* Send received datagram back to the client */ sendto(sock, echoBuffer, recvMsgSize, 0, (struct sockaddr *) &echoClntAddr, sizeof(echoClntAddr); } } /* end of main () */

Error handling is must

88

Transport Layer

• Part 1 : TCP, UDP• Part 3 : TCP Flow Control and Congestion Control• Part 2 : Socket Programming• Part 4 : TCP in Wireless Network, Real-Time Transport


TCP over Wireless Networks

90

Outline for TCP over Wireless Networks

• TCP over Wireless: Problems• TCP over Wireless: Solutions

– Link-layer based– Split TCP– TCP-aware link layer– Explicit notification

• Summary• Hop: a Reliable Hop-by-hop Block Transfer

Protocol

91

TCP over Wireless: Problems

• Disambiguating wireless bit-errors from congestion– Frequent window reduction due to errors– Frequent timeout due to burst losses

• High variability– Contention + channel errors high loss– Contention + link-layer retransmission high RTT variance

• Need end-to-end connection all the time– Wireless links have intermittent connectivity

92

Outline




Protocol

93

Link-layer based Schemes: ARQ

• Automatic Repeat reQuest (ARQ)– Widely used in wireless link-layer protocols– Uses retransmissions and acks to cover wireless errors

Packet 1

Link-Ack 1

Packet 2

Link-Ack 2

Packet 3

Packet 3

Timeout

Link-Ack 3

Internet

FH BS MH

Link-Layer

ARQ

94

Link-layer based Schemes: ARQ

• Pros– No modification to upper layers

• Cons– Fast retransmission due to message lost and out-of-order delivery —redundant retransmission and window reduction

– Interacts with TCP retransmissions —redundant retransmission

• H. Balakrishnan, et al. A comparison of mechanisms for improving TCP performance over wireless links, Sigcomm96

– Large RTT variance —long timeout

– Head-of-line blocking due to large #retransmission —slow link blocks fast link

95

Outline




Protocol

96

Split TCP: Indirect TCP

• I-TCP splits end-to-end TCP connection into two connections– Fixed host to BS– BS to mobile host

• Two TCP connections with independent flow/congestion control contexts• Packets buffered at BS

Internet

FH BS MH

TCP TCPBuffer

97

Split TCP: Indirect TCP

• Pros– Separates flow and congestion control of wireless and wired --higher throughput at sender

• Cons– Breaks TCP end-to-end semantics

• Ack at FH does not mean MH has received the packet

– BS failure causes loss of data• Neither FH nor MH can recover the data

– On path change, data has to be forwarded to new BS

– Wireless part is the bottleneck

98

Split TCP: Selective Repeat Protocol• Similar to I-TCP but uses SRP/UDP over wireless link

– Raj Yavatkar, Namrata Bhagawat, Improving End-to-End Performance of TCP over Mobile Internetworks, 1994

• Pros– Better performance over wireless links

• Cons– All cons of I-TCP except last one

Internet

FH BS MH

TCP SRP/UDPBuffer

99

Split-TCP: Mobile TCP

• Similar to I-TCP but tries to keep TCP end-to-end semantics

• BS only acks the last packet after it is received by MH– Kevin Brown and Suresh Singh. A network architecture for mobile computing. In Proc. IEEE INFOCOM'96, March 1996

• Pros– Data will be recovered eventually after BS failure– BS buffer does not overflow

• Cons– Worse performance– Still not exactly the TCP semantics

100

Outline



• Summary• Hop: a Reliable Hop-by-hop Block Transfer Protocol

101

TCP-aware Link Layers: Snoop• Link layer is aware of TCP traffic• BS caches data and monitors acks. Retransmits on duplicate acks

and drops duplicate acks– H. Balakrishnan, et al. Improving TCP/IP Performance over Wireless Networks, 1995

Internet

FH BS MH

Packet 1

Ack 1Packet 2

Ack 2

Packet 3

Packet 4

Ack 2

Packet 1

Ack 1

Packet 2

Ack 2Packet 3

Packet 4

Packet 3

Blocks Dup-Ack

102

TCP-aware Link Layers: Snoop

• Pros– No modification to FH and MH– BS only keeps soft state—BS failure does not break

TCP• Cons

– Does not work with encrypted packets– Does not work if data packets and acks traverse

different paths– Increases RTT—high timeout

103

TCP-aware Link Layers: WTCP• Similar to Snoop• WTCP corrects RTT by modifying the timestamp in return acks

– K. Ratnam and I. Matta ,WTCP: An Efficient Transmission Control Protocol for Networks with Wireless Links, 1998

Internet

FH BS MH

Packet 3

Packet 4

Ack 2

Packet 3

Ack’ 3

Packet 4

Packet 3

Ack 3

Log Arrival Time

Arrival Time+=Delay

Delay

105

Outline




Protocol

106

Explicit Notification: Explicit Loss Notification [ELN]

• ELN works with MH is the sender• BS monitors TCP segments from MH and logs down holes • BS tags a dup-ack’s ELN bit if corresponds to a logged hole• No congestion control on MH if an ELN-ack is received

– Hari Balakrishnan and Randy H. Katz, Explicit Loss Notification and Wireless Web Performance, 1998

Internet

FH BS MH

Packet 1

Ack 1

Packet 2

Packet 3

Packet 4

Packet 1

Packet 3

Packet 4

Ack 1

Ack 1

Log Hole(Pkt 2)

Ack 1(ELN)

Ack 1(ELN)

Ack 1

107

RTP

• Real-time Transport Protocol (RTP) is the protocol designed to handle real-time traffic on the Internet. RTP does not have its delivery mechanism; it must be used with UDP. RTP stands between UDP and the application program. The main contributions of RTP are time-stamping, sequencing, and mixing facilities.

RTP Packet Format

UDP Port

Topics discussed in this section:

108

Figure : RTP

109

Figure: RTP packet header format

110

Table Payload types

111

RTP uses a temporary even-numbered UDP port.

Note

112

RTCP

• RTP allows only one type of message, one that carries data from the source to the destination. In many cases, there is a need for other messages in a session. These messages control the flow and quality of data and allow the recipient to send feedback to the source or sources. Real-time Transport Control Protocol (RTCP) is a protocol designed for this purpose.

Sender Report and Receiver Report

Messages

UDP Port


113

• Figure RTCP message types

114

RTCP uses an odd-numbered UDP port number that follows the port

number selected for RTP.

Note

115

Transport Layer

• Part 1 : TCP, UDP• Part 3 : TCP Flow Control and Congestion Control• Part 2 : Socket Programming• Part 4 : TCP in Wireless Network, Real-Time Transport

Protocol• Part 5 : Stream Control Transmission Protocol [SCTP]• Part 6 : Quality of Service(QoS), Differentiated Services, Integrated Services

116

SCTP

• Stream Control Transmission Protocol (SCTP) is a new reliable, message-oriented transport layer protocol. SCTP, however, is mostly designed for Internet applications that have recently been introduced. These new applications need a more sophisticated service than TCP can provide.

SCTP Services and Features

Packet Format

An SCTP Association

Flow Control and Error Control


117

SCTP is a message-oriented, reliable protocol that combines the best

features of UDP and TCP.

119

Figure Multiple-stream concept

120

An association in SCTP can involve multiple streams.

121

Figure Multihoming concept

122

SCTP association allows multiple IP addresses for each end.

123

In SCTP, a data chunk is numbered using a TSN [SCTP seq no].

124

To distinguish between different streams, SCTP uses an SI [stream id].

125

To distinguish between different data chunks belonging to the same

stream, SCTP uses SSNs.

Note

126

TCP has segments; SCTP has packets.

Note

127

Figure 23.29 Comparison between a TCP segment and an SCTP packet

128

In SCTP, control information and data information are carried in

separate chunks.

130

Data chunks are identified by three items: TSN, SI, and SSN.

TSN is a cumulative number identifying the association; SI defines the

stream; SSN defines the chunk in a stream.

131

In SCTP, acknowledgment numbers are used to acknowledge only

data chunks;

control chunks are acknowledged by other control chunks if

necessary.

132

Figure SCTP packet format

133

In an SCTP packet, control chunks come before data chunks.

136

A connection in SCTP is called an association.

Note

137

Service/Features SCTP TCP UDP

Message-Oriented YES NO YES

Byte-Oriented NO YES NO

Connection-Oriented YES YES NO

Full Duplex YES YES YES

Reliable data transfer YES YES NO

Partially-Reliable data transfer OPT NO NO

Ordered data delivery YES YES NO

Unordered delivery YES NO YES

Flow control YES YES NO

Congestion Control YES YES NO

ECN Capable YES YES NO

Selective Acknowledgments YES OPT NO

139

Transport Layer

• Part 1 : TCP, UDP• Part 2 : Socket Programming• Part 3 : TCP Flow Control and Congestion Control• Part 4 : TCP in Wireless Network, Real Time Transport


140

QUALITY OF SERVICE

• Quality of service (QoS) is an internetworking issue that has been discussed more than defined. We can informally define quality of service as something a flow seeks to attain.

141

Flow characteristics

142

TECHNIQUES TO IMPROVE QoS

• In this Section, defined is QoS in terms of its characteristics. we discuss some techniques that can be used to improve the quality of service.

• Four common methods: scheduling, traffic shaping, admission control, and resource reservation.

143

Figure FIFO queue

144

Figure Priority queuing

145

Figure Weighted fair queuing

146

Figure Leaky bucket

147

Figure Leaky bucket implementation

148

A leaky bucket algorithm shapes bursty traffic into fixed-rate traffic by

averaging the data rate. It may drop the packets if the bucket is full.

Note

149

The token bucket allows bursty traffic at a regulated maximum rate.

Note

150

Figure Token bucket

151

INTEGRATED SERVICES

• Two models have been designed to provide quality of service in the Internet: Integrated Services and Differentiated Services.

• We discuss the first model here.

152

Integrated Services is a flow-based QoS model designed for IP.

153

IETF Intserv

• Focus on per-flow QoS.– Support specific applications such as video

streaming.– Based on mathematical guarantees.

• Many concerns:– Complexity– Scalability– Business model– Charging

154

Components of Integrated Services

• Type of service model– What does the network promise?

• Service interface– How does the application describe what it wants?

• Packet scheduling– How does the network meet promises?

• Establishing the guarantee– How is the promise communicated to/from the

network?– How is admission of new applications controlled?

155

Service Models

• Network can support traffic streams with different “quality of service”.– Best effort– Predictive or differentiated services– Strong guarantees on the level of service (real-time)

• The set of services that is supported on a specific network can be viewed as a service model.– Model that can be used to select a service

• E.g., cost versus performance tradeoffs– Network architecture that supports the set of services

• Considers interactions between services

156

Service Models

• Guaranteed service– Targets hard real-time applications.– User specifies traffic characteristics and a service requirement.– Requires admission control at each of the routers.– Can mathematically guarantee bandwidth, delay, and jitter.

• Controlled load.– Targets applications that can adapt to network conditions within a certain

performance window.– User specifies traffic characteristics and bandwidth.– Requires admission control at each of the routers.– Guarantee not as strong as with the guaranteed service.

• e.g., measurement-based admission control.

• Best effort

157

Service Interface

• Session must first declare its QoS requirement and characterize the traffic it will send through the network

• R-spec: defines the QoS being requested by receiver (e.g., rate r)

• T-spec: defines the traffic characteristics of sender (e.g., leaky bucket with rate r and buffer size b).

• A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol.

158

Packet scheduling

• Guaranteed service– Use token bucket filter to characterize traffic

• Described by rate r and bucket depth b

– Use WFQ at the routers– Parekh’s bound for worst case queuing delay = b/r

159

Call Admission

• Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

RSVP

The ReSerVation Protocol

161

RSVP, Is it required?

• QOS Requirements??• Real-time applications

– Interactive applications are sensitive to packet delays (telephone)

– Non-interactive applications can adapt to a wider range of packet delays (audio, video broadcasts)

– Guarantee of maximum delay is useful

162

QOS Required??

• What is the problem?– Different applications have different delay,

bandwidth, and jitter needs– Some applications are very sensitive to

changing network conditions: the packet arrival time distribution is important

• Solutions– Make applications adaptive– Build more flexibility into network

163

What is RSVP?

• Protocol that guarantees QoS • It reserves resources in the internet (resources

include BW and router buffers)• Can also be used by routers to forward BW

reservation requests

164

Definition

• RSVP: It is a network control protocol that allows data receiver to request a special end to end quality of service for its data flows.

• Although it sits on top of the IP protocol stack, it is not a routing protocol

• It is rather an internet control protocol• It is designed to operate with current and

future unicast and multicast routing protocols

165

Principal characteristics

• Reservations for BWs in multicast trees• Unicast is handled as a degenerate case of

multicast• It is receiver oriented ie… receiver of data

initiates the process

166

Session

• Similar to RTP here also session consists of multiple multicast data flows

• Each sender is a source of one or more data flows

• Each data flow in a session has a same multicast address

167

What RSVP is not?

• It does not specify how the network provide the reserved BW to the data flows

• Routers will actually provide the reserved BW (via priority scheduling etc).

• It is not a routing protocol (it does not determine the links)

• Also referred as signaling protocol.

168

Heterogeneous receivers

• Some receivers can receive at 30 Kbps others at 128 Kbps and others at 10Mbps

Suppose if a sender is multicasting a video to a group of heterogeneous receivers ,should the sender encode the video for 30,128Kbps or 10Mbps?

169

solution

• Layered encoding is often suggested • Sender need not know the receiving rates of

all the receivers• Only need to know the maximum speed of the

receivers• RSVP mainly deals with the heterogeneous

receivers

170

Reservation Merging ex 1

Receiver#1

Receiver#2

Receiver#3

Reservations mergeas they travel up tree.

R6

R3

R1

R4 R7

(1) 50Kbs

(2) 50Kbs

(3) 50Kbs

(4) 100 Kbs

(5) 100 Kbs

(6) 100 Kbs

(7) 100 Kbs

(8) 60Kbs

(9) 60Kbs

171

Reservation merging ex 2

172

Call admission

• BW reserved by the router should not exceed the links capacity

• So a router first determines its down stream links can accommodate the reservation or not.

• RSVP do not define this admission tests.

173

Local decision modules

• Admission control• Policy control

Proceeded only when these two are verifiedIf either check fails RSVP will return an error.

174

Soft state

• There is a timer associated with every reservation of BW stored in a router

• It should be periodically refreshed.• Same principle is used for routing tables

where the entries are refreshed by newly arriving data packets

175

1.Soft State: RSVP takes a soft state approach to manage the reservation state in routers and hosts.A soft state is created and periodically refreshed by Path and Resv messages.

2. Teardown: It is used to remove path or reservation state immediately.Two Types: 1. PathTear-travels downstream 2. ResvTear -travels upstream

176

3. Errors: The two killer reservation problems: 1. KR-1-It arises when already there is a Q0 in place and if another receiver makes a larger Q1>Q0, the result of merging may be rejected by some intermediate node. Solution: In case of failure, any existing reservation is kept in place. 2.KR-II-The receiver is trying to make a reservation of Q1 even though admission control is failing for it in some node.This must not prevent a Q0 <Q1 from establishment. Solution: Blockade State.

177

• Blockade State: A blocked state in a node modifies the merging process to omit the offending flowspec.

• When a ResvErr message is received , its flowspec Qe is used to create or refresh an element of local blockade state.

• Each element of blocked state consists of a blocked flowspec Qb taken from the error message and a associated blockade timer Tb.

• When a blockade timer expires , the corresponding blockade state is deleted.

178

Reservation styles

179

Reservation styles

• 1.Wildcard Filter (WF) Style: It creates a single reservation shared by flows from all upstream senders WF(*(Q))*- represents the wildcard sender selectionQ-flow spec2. Fixed Filter (FF): It creates a distinct reservation for data packets from a particular sender. FF(S(Q))3. Shared Explicit (SE): It creates a single reservation shared by selected upstream senders.SE((S1,S2,..)(Q))

RSVP Protocol Mechanisms

Router

CA

D

D’

B

B’

1

181

• There are two fundamental RSVP messages:1.Path2. Resv

• Each receiver host sends a Resv message upstream towards the senders.

• These messages must follow the exact reverse path the data will use.

• They create and maintain the reservation state in each node along the path.

182

• Path: Each RSVP sender host transmits a Path message downstream.

• These store the ‘path state’ in each node along the way.• This path state includes the IP address of the previous hop

node which is used to route the Resv message in the reverse direction.

• Each Path message contains the following information:1.Sender Template: Describes the format of data packets

that the sender will originate.2.Sender Tspec: Defines the traffic characteristics of the

data flow.3.Adspec: Used for OPWA.

183

Path messages

184

Resv messages

185

Describing and Identifying a Flow

• Flow spec defines traffic parameters– Traffic parameters: bandwidth, buffering

requirements– Uses token bucket specification

• Filter spec identifies packets in flow– Simplest filter: Source, Dest address/port pair– Data filter: classifies packets according to contents

186

Resource Reservation

• Senders advertise using PATH message• Receivers reserve using RESV message

– Flowspec + filterspec + policy data– Travels upstream in reverse direction of Path

message• Sender/receiver notified of changes

187

Components of path

• Each Path message contains the following information:1.Sender Template: Describes the format of data

packets that the sender will originate.2.Sender T- spec: Defines the traffic characteristics

of the data flow.3.Adspec: Used for OPWA (One Pass with

Advertisement)• With this scheme, RSVP control packets are sent

downstream , flowing the data paths to gather information that can be used to predict the end to end QoS.

188

Killer reservation problem

• It arises when already there is a Q0 in place and if another receiver makes a larger Q1>Q0, the result of merging may be rejected by some intermediate node.

• Blockade State: A blocked state in a node modifies the merging process to omit the offending flowspec.

189

RSVP routing problems

• If route changes, reservation must be made along new route– New reservation takes time to setup– New reservation might fail– Old route could still be working fine

• Reservation failure– Primary route has inadequate bandwidth

although secondary has enough

190

DIFFERENTIATED SERVICES [DS]

• Differentiated Services (DS or Diffserv) was introduced by the IETF (Internet Engineering Task Force) to handle the shortcomings of Integrated Services.

191

Differentiated Services

• Intended to address the following difficulties with Intserv and RSVP;

• Scalability: maintaining states by routers in high speed networks is difficult due to the very large number of flows

• Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …)

• Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service

192

Diffserv - Motivation

• Do fine-grained enforcement only at the edge of the network.– Typically slower links at edges– E.g., mail sorting in post office

• Label packets with a field.– E.g., a priority stamp

• The core of the network uses only the type field for QoS management.– Small number of types with well defined forwarding behavior– Can be handled fast

• Example: expedited service versus best effort• Evolution rather than revolution

193

Diffserv - Discussion

• Diffserv defines an architecture and a set of forwarding behaviors.– It is up to the service providers to define and implement end-to-end

services on top of this architecture.– Offers a more flexible service model; different providers can offer

different service.• One of the main motivations for Diffserv is scalability.

– Keep the core of the network simple.• Focus of Diffserv is on supporting QoS for flow aggregates.

– Although architecture does not preclude more fine-grained guarantees.

194

Edge Router/Host Functions

• Classification: marks packets according to classification rules to be specified.

• Metering: checks whether the traffic falls within the negotiated profile.

• Marking: marks traffic that falls within profile.

• Conditioning: delays and then forwards, discards, or remarks other traffic.

195

Classification and Conditioning

• Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6.

• 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive.

• 2 bits are currently unused.

196

Core Functions

• Forwarding: according to “Per-Hop-Behavior” or PHB specified for the particular packet class; such PHB is strictly based on class marking (no other header fields can be used to influence PHB).

BIG ADVANTAGE:• No state info to be maintained by routers!

197

Differentiated Services is a class-based QoS model designed for IP.

198

Traffic conditioner

Documents

UNIT –II Transport Layer Prof. Nalini Mhetre, Dept. of Computer Engg. SKNCOE, Pune