Transcript Lektion 1-Introduktion

Multimedie- och
kommunikationssystem
Föreläsning 11
Kapitel 12: Transportprotokoll. Flödesstyrning och
trafikstockningshantering. Sliding window.
Transport layer duties
Figure 22.1 Types of data deliveries
Virtual Connection at the Transport Layer
Host
Router
Router
Application
Application
TCP, UDP
IP
Physical
Protocol stack
in the host
Host
TCP, UDP
IP
IP
Physical
Physical
Protocol stack in
the router
IP
Physical
Protocol stack
in the host
Figure 22.5
Socket address
A socket is a data flow between two processes
that is identified by its socket address pair, i.e.
a unique combination of:
- Transport protocol (UDP or TCP).
- Source IP address and port number.
- Destination IP address and port number.
Figure 22.7
Connection establishment
Figure 22.8
Connection termination
Client-Server Paradigm
 Used most often in Internet process-to-process communication, for
example, email, web, file transfer, etc.
 The client process initiates the communication.
 The server process waits for the client to initiate communication, and
responds by sending the information required. Example: Web server,
email server, ftp server, etc.
 A firewall often stops external clients from accessing internal servers,
except certain web
 Opposite: Peer-to-peer communication, where a program can act both as
client (taking initiative) and server (responding to other).
User Datagram Protocol (UDP)
 UDP is a connectionless, unreliable protocol that has no flow and error
control.
 No connection management.
 It solely provides a mechanism multiplexing data from the application
layer and demultiplexing at the receiver end by means of port numbers.
 Use predominantly by protocols that do no require the strict service
guarantees offered by TCP (e.g. real-time multimedia protocols).
 It is also used for applications that provide flow and error control (e.g.
LAN-services such as shared disk access)
 Additional intelligence built at the application layer if needed.
Figure 12.20 (a) UDP header fields
The calculation of checksum and its inclusion in
the user datagram are optional.
Table 22.1 Well-known ports used by UDP
Port
Protocol
Description
7
Echo
Echoes a received datagram back to the sender
9
Discard
11
Users
13
Daytime
17
Quote
19
Chargen
53
Nameserver
67
Bootps
Server port to download bootstrap information
68
Bootpc
Client port to download bootstrap information
69
TFTP
Trivial File Transfer Protocol
111
RPC
Remote Procedure Call
123
NTP
Network Time Protocol
161
SNMP
Simple Network Management Protocol
162
SNMP
Simple Network Management Protocol (trap)
Discards any datagram that is received
Active users
Returns the date and the time
Returns a quote of the day
Returns a string of characters
Domain Name Service
Figure 12.19 (b) UDP socket primitives: and their use.
Transmission Control protocol (TCP)
 Provides a connection-oriented end-to-end (user-to-user) reliable
byte stream service in both directions (full duplex)
 Divides a byte stream into a sequence of segments and sends them
to the destination via IP
 Uses the destination port, source port to identify the application
to which the segment is sent (multiplexing the sessions)
 Uses sliding window like scheme for flow control and congestion
control
TCP Header Fields
Figure 22.15
Control field
Table 22.2 Well-known ports used by TCP
Port
Protocol
Description
7
Echo
9
Discard
11
Users
13
Daytime
17
Quote
19
Chargen
20
FTP, Data
21
FTP, Control
23
TELNET
25
SMTP
53
DNS
67
BOOTP
79
Finger
Finger
80
HTTP
Hypertext Transfer Protocol
111
RPC
Echoes a received datagram back to the sender
Discards any datagram that is received
Active users
Returns the date and the time
Returns a quote of the day
Returns a string of characters
File Transfer Protocol (data connection)
File Transfer Protocol (control connection)
Terminal Network
Simple Mail Transfer Protocol
Domain Name Server
Bootstrap Protocol
Remote Procedure Call
Figure 22.11 Stream delivery
Figure 22.12
Sending and receiving buffers
Figure 22.13 TCP segments
TCP Sliding Window
segment 1
100 bytes of data numbered from
1 to 100
acknowledge 801
segment 2
100 bytes of data numbered from
701 to 800, ack 101
acknowledge 101
segment 1
100 bytes of data numbered from
101 to 200, ack 801
acknowledge 901
segment 3
100 bytes of data numbered from
801 to 900, ack 201
acknowledge 201
segment 2
Note:
The bytes of data being transferred in
each connection are numbered by
TCP. The numbering starts with a
randomly generated number.
Note:
The value of the sequence number
field in a segment defines the number
of the first data byte contained in that
segment.
Example 1
Imagine a TCP connection is transferring a file of 6000 bytes. The
first byte is numbered 10010. What are the sequence numbers for
each segment if data are sent in five segments with the first four
segments carrying 1000 bytes and the last segment carrying 2000
bytes?
Solution
The following shows
Segment 1 ==>
Segment 2 ==>
Segment 3 ==>
Segment 4 ==>
Segment 5 ==>
the sequence number for each segment:
sequence number: 10,010 (range: 10,010
sequence number: 11,010 (range: 11,010
sequence number: 12,010 (range: 12,010
sequence number: 13,010 (range: 13,010
sequence number: 14,010 (range: 14,010
to 11,009)
to 12,009)
to 13,009)
to 14,009)
to 16,009)
Note:
The value of the acknowledgment field
in a segment defines the number of the
next byte a party expects to receive.
The acknowledgment number is
cumulative.
Connection Management
 Two way handshake protocol is not enough because of potential delays in either A’s
request or B’s responce, as shown below. Possibility of confusion exists.
A
B
A sends a
t1
connection request
A sends connection
t2
request again
A receives the
acknowledgement
and establishes a t4
connection
t3
A and B exchange
data and eventually
disconnect
time
B receives connection
request
B establishes a
connection and sends
an acknowledgement
B receives connection
t5 request
B establishes a
connection and sends
an acknowledgement
time
Three-way Handshake Protocol for Connection
Establishment
A
A sends a connection
request with seq. no. x
B
t1
A sends connection request t2
again with seq. no. y
A receives the
acknowledgement y+1 and t4
sends acknowledgement z+1
A does not send an
acknowledgement and no
connection is established
t3 B sends acknowledgement
y+1 and seq. no. z
The connection is
established
t5 B sends acknowledgement
x+1 and seq. no. w
t6
time
time
Connection Establishment and Termination
Active open
SYN
Send connection
request
SYN+ACK
Server does passive open
Accept connection request
Send acceptance
ACK
DATA
Start connection
The three-way handshake TCP
segments are labeled with SYN.
The length of data in the first two
is 0
 3-way handshake used for
connection establishment
 Randomly chosen sequence
number is conveyed to the
other end
 Similar FIN, FIN+ACK
exchange used for
connection termination
Figure 22.16 Three-step connection establishment
1) Request.
2) Acknowledgement of the request.
3) Acknowledgement of the acknowledgement.
Window Management in TCP
• Sliding window scheme is used with variable window
○ The window can change depending on the traffic in the network
(TCP provides congestion control)
• The size of the window is expressed in bytes instead of
packets
• The window size depends on the receiver’s capabilites and
the congestion in the network
Figure 12.9 TCP sliding window.
Note:
In TCP, the sender window size is
totally controlled by the receiver
window value (the number of empty
locations in the receiver buffer).
However, the actual window size can
be smaller if there is congestion in the
network.
Figure 12.11 TCP congestion window adjustments: (a)
on receipt of duplicate ACKs;
Figure 12.11 TCP congestion window adjustments
(b) on expiry of a retransmission timer.
Figure 23.6
Packet delay and network load
Figure 23.7 Throughput versus network load
Note:
If the cause of the lost segment is
congestion, retransmission of the
segment does not remove
the cause—it aggravates it.
Note:
TCP assumes that the cause of a lost
segment is due to congestion
in the network.
Figure 23.8
Multiplicative decrease
Figure 12.10
TCP
congestion
control
window
procedure.
23.6 Techniques to Improve QoS
Scheduling
Traffic Shaping
Resource Reservation
Admission Control
Figure 23.12
Flow characteristics
Figure 23.13
FIFO queue
Figure 23.14
Priority queuing
Figure 23.15 Weighted fair queuing
Figure 23.16
Leaky bucket
Figure 23.17
Leaky bucket implementation
Note:
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.
Figure 12.21 Real-time transport protocol (RTP)
(a) usage
A protocol for real-time traffic; used in conjunction with UDP.
Figure 12.21 Real-time transport protocol (RTP)
(b) packet format.
Figure 12.22 Real-time transport control protocol
(RTCP) usage.
A companion protocol to RTP with messages that control the flow and quality
of data and allow the recipient to send feedback to the source or sources.
Figure 23.5
Incoming packet
Figure 9.28 QoS support mechanisms: (a) RSVP
principles;
RSVP = Resource Reservation Protocol.
A signalling protocol to help IP create a flow and improve QoS.
Reserves resources in each router, for unicasting
and multicasting traffic flows with guaranteed QoS.
DiffServ
architecture.
DiffServ = Differentiated services
A class-based QoS model.
Flows are aggregated into service classes.
The IP header Type-of-service field
is replaced by a DiffServ field.
CR = core router
I/ER = ingress/egress router
MF = multifield
BA = behavior aggregate
PHB = per-hop behavior
Figure 14.4 Example showing the sequence of
messages exchanged for a local name resolution.
Service classes
CBR = Constant Bit Rate
VBR = Variable Bit Rate
ABR = Available Bit Rate
UBR = Unspecified Bit Rate (best-effort)
Figure 23.28
Relationship of service classes to the total capacity