end to end protocolsmy.fit.edu/~gmarin/cse5231/oldtransportlayersect5.pdftransport-layer protocols....

Network Analysis: EndToEnd 5-1

End to End Protocols

This material is provided solely for the use of students in CSE5231 at FIT. Further use or reproduction may be a violation of existing copyright protection.


Transport Layergoals:

understand principles behind transport layer services:

multiplexing/demultiplexingreliable data transferflow controlcongestion control

instantiation and implementation in the Internet

Common Properties:Guarantees message deliveryDelivers messages in orderSupports arbitrarily large messagesMay support synchronization between sender and receiver.Supports flow control to protect the receiver.May support congestion control to support the network.Supports multiple application processes on each host.


Recall limitations of “best-effort” internetwork

It may drop messages.It may reorder messages.It may deliver duplicate copies of a given message.It may limit message size in some way.It may allow arbitrarily long delay.It may allow large variability in delay from packet to packet. End to end protocols may need to compensate for these limitations.


Transport services and protocols

provide logical communicationbetween app’ processes running on different hoststransport protocols run in end systems transport vs network layer services:network layer: data transfer between end systemstransport layer: data transfer between processes

relies on, enhances, network layer services

applicationtransportnetworkdata linkphysical


networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical


Transport-layer protocols

Internet transport services:reliable, in-order unicast delivery (TCP)

congestion flow controlconnection setup

unreliable (“best-effort”), unordered unicast or multicast delivery: UDPservices not available:

real-timebandwidth guaranteesreliable multicast






networkdata linkphysicalnetwork

data linkphysical


applicationtransportnetwork

M P2applicationtransportnetwork

Multiplexing/demultiplexingRecall: segment - unit of data

exchanged between transport layer entities

aka TPDU: transport protocol data unit

receiver

HtHn

Demultiplexing: delivering received segments to correct app layer processes

segmentsegment M

applicationtransportnetwork

P1M

M MP3 P4

segmentheader

application-layerdata


Multiplexing/demultiplexing

multiplexing/demultiplexing:based on sender, receiver port numbers, IP addresses

source, dest port #s in each segmentrecall: well-known port numbers for specific applications

16 bits implies 64k ports available

gathering data from multipleapp processes, enveloping data with header (later used for demultiplexing)

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

Multiplexing:


Multiplexing/demultiplexing: examples

host A server Bsource port: xdest. port: 23

source port:23dest. port: x

port use: simple telnet app

Web clienthost A

Webserver B

Web clienthost C

Source IP: CDest IP: B

source port: xdest. port: 80

Source IP: CDest IP: B

source port: ydest. port: 80

port use: Web server

Source IP: ADest IP: B

source port: xdest. port: 80


WELL KNOWN PORT NUMBERS The Well Known Ports are assigned by the IANA and on most systems can only be used by system (or root) processes or by programs executed by privileged users. Ports are used in the TCP [RFC793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. The contact port is sometimes called the "well-known port". To the extent possible, these same port assignments are used with the UDP [RFC768]. The range for assigned ports managed by the IANA is 0-1023.


Port Examples:chargen 19/tcp Character Generatorchargen 19/udp Character Generator ftp-data 20/tcp File Transfer [Default Data] ftp-data 20/udp File Transfer [Default Data] ftp 21/tcp File Transfer [Control] ftp 21/udp File Transfer [Control]ssh 22/tcp SSH Remote Login Protocol ssh 22/udp SSH Remote Login Protocol telnet 23/tcp Telnet telnet 23/udp Telnet24/tcp any private mail system 24/udp any private mail systemsmtp 25/tcp Simple Mail Transfer smtp 25/udp Simple Mail Transfer26/tcp Unassigned # 26/udp Unassigned


UDP: User Datagram Protocol [RFC 768]

“no frills,” “bare bones” Internet transport protocol“best effort” service, UDP segments may be:

lostdelivered out of order to app

connectionless:no handshaking between UDP sender, receivereach UDP segment handled independently of others

Why is there a UDP?no connection establishment (which can add delay)simple: no connection state at sender, receiversmall segment headerno congestion control: UDP can blast away as fast as desired


UDP: moreoften used for streaming multimedia apps

loss tolerantrate sensitive

other UDP uses (why?):

DNSSNMP

reliable transfer over UDP: add reliability at application layer

application-specific error recovery!

source port # dest port #32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header


UDP checksum – Optional v4

Sender:treat segment contents as sequence of 16-bit integerschecksum: addition (1’s complement sum) of segment contentssender puts checksum value into UDP checksum field

Receiver:compute checksum of received segmentcheck if computed checksum equals checksum field value:

NO - error detectedYES - no error detected. But maybe errors nonethless? More later ….

Goal: detect “errors” (e.g., flipped bits) in transmitted segment including UDP header, pseudo-header, data.


UDP Pseudo-header

Consists of three fields from the IP header

Protocol numberSource IP addressDestination IP address

Plus UDP Length field


Principles of Reliable data transferimportant in app., transport, link layerstop-10 list of important networking topics!

characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)


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,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


TCP (Transmission Control Protocol)

Offers a reliable, connection-oriented, byte-stream service.Full-duplex (one byte-stream in each direction)Supports multiplexing/demultiplexing among multiple applications on a host.Implements flow controlImplements congestion control


Development of TCP/IP

Early 1970s Vinton Cerf and Robert Kahn recognized the importance of creating a single protocol for packet-switched networks.Initially they saw it as a single entity. Later split into TCP and IP. Published paper in IEEE Transactions on Communications Technology – May 1974.Before the web, before LANs, before PCs…


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

full duplex data:bi-directional data flow in same connectionMSS: 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

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data


TCP segment structure

source port # dest port #32 bits

applicationdata

(variable length)

sequence numberacknowledgement number

rcvr window sizeptr urgent datachecksum

FSRPAUheadlen

notused

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)


TCP Pseudo Header

32-bit source IP address32-bit destination IP address8-bit protocol number16-bit TCP header+data length

TCP checksum covers the above plus:TCP headerTCP data


TCP Challenges

RTTs can be long (100s of ms) and variable.Connections may be between any two hosts on the Internet (can’t assume much)Packets may arrive very late.Hosts are generally “tuned” to their local link and buffer sizes, for example, may vary greatly. Sender has no idea where the bottleneck may be in the network and at what max bandwidth.


TCP seq. #’s and ACKsSeq. #’s:

byte stream “number” of first byte in segment’s data

ACKs:seq # of next byte expected from other sidecumulative ACK

Q: how receiver handles out-of-order segments

A: TCP spec doesn’t say, - up to implementor

Host A Host B

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of‘C’, echoes

back ‘C’

timesimple telnet scenario


TCP: reliable data transfer

simplified sender, assuming

waitfor

event

waitfor

event

event: data received from application above

event: timer timeout for segment with seq # y

event: ACK received,with ACK # y

create, send segment

retransmit segment

ACK processing

•one way data transfer•no flow, congestion control


TCP ACK generation [RFC 1122, RFC 2581]

Event

in-order segment arrival, no gaps,everything else already ACKed

in-order segment arrival, no gaps,one delayed ACK pending

out-of-order segment arrivalhigher-than-expect seq. #gap detected

arrival of segment that partially or completely fills gap

TCP Receiver action

delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

immediately send singlecumulative ACK

send duplicate ACK, indicating seq. #of next expected byte

immediate ACK if segment startsat lower end of gap


TCP: retransmission scenariosHost A

loss

tim

eout

time lost ACK scenario

Host B

X

Host A

Seq=

92 t

imeo

uttime premature timeout,

cumulative ACKs

Host B

Seq=

100

tim

eout


TCP Flow Controlreceiver: explicitly

informs sender of (dynamically changing) amount of free buffer space

RcvWindow field in TCP segment

sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow

sender won’t overrunreceiver’s buffers by

transmitting too much,too fast

flow control

receiver buffering

RcvBuffer = size of TCP Receive Buffer

RcvWindow = amount of spare room in Buffer


TCP Round Trip Time and Timeout

Q: how to set TCP timeout value?longer than RTT

note: RTT will varytoo short: premature timeout

unnecessary retransmissions

too long: slow reaction to segment loss

Q: how to estimate RTT?SampleRTT: measured time from segment transmission until ACK receipt

ignore retransmissions, cumulatively ACKed segments

SampleRTT will vary, want estimated RTT “smoother”

use several recent measurements, not just current SampleRTT


TCP Round Trip Time and Timeout

EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT

Exponential weighted moving averageinfluence of given sample decreases exponentially fasttypical value of x: 0.1

Setting the timeoutEstimtedRTT plus “safety margin”large variation in EstimatedRTT -> larger safety margin

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation +x*|SampleRTT-EstimatedRTT|


TCP Connection Management

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

seq. #sbuffers, flow control info (e.g. RcvWindow)

client: connection initiatorSocket clientSocket = new Socket("hostname","port

number");

server: contacted by clientSocket connectionSocket = welcomeSocket.accept();

Three way handshake:Step 1: client end system

sends TCP SYN control segment to server

specifies initial seq #

Step 2: server end system receives SYN, replies with SYNACK control segment

ACKs received SYNallocates buffersspecifies server-> receiver initial seq. #


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 server

close

close

closed

tim

ed w

ait


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.

client server

closing

closing

closed

tim

ed w

ait

closed


TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle


Triggering TCP Transmission

1. Segment is sent as soon as it reaches the max segment size, MSS.

MSS is the local MTU – TCP hdr size – IP hdr size.

2. Segment is sent if application uses “push.”3. Segment is sent if sending timer pops.

Avoid the “silly window syndrome” in which small segments are introduced (via flow control from nearly-full receiver buffer) and never re-collected.


Nagle’s Algorithm

Send a full segment (size MSS) if window allows.Send a smaller segment if no other outstanding segments.If there are segments outstanding, then wait for an “ack” before sending another segment (unless = MSS).


Principles of Congestion Control

Congestion:informally: “too many sources sending too much data too fast for network to handle”different from flow control!manifestations:

lost packets (buffer overflow at routers)long delays (queueing in router buffers)

a top-10 problem!


Causes/costs of congestion: scenario 1

two senders, two receiversone router, infinite buffers no retransmission

large delays when congestedmaximum achievable throughput



one router, finite buffers sender retransmission of lost packet


Causes/costs of congestion: scenario 3four sendersmultihop pathstimeout/retransmit

λin

Q: what happens as and increase ?λ

in



Another “cost” of congestion:when packet dropped, any “upstream transmission capacity used for that packet was wasted!

Network Analysis: Resources & Congestion

6-41

Definitions

Resource allocation is “the process by which network elements try to meet the competing demands that applications have for network resources – primarily link bandwidth and buffer space in routers or switches.”

Include labels in the case of label swapCongestion control describes “the efforts made by network nodes to prevent or respond to overload conditions.”


6-42

Causes of CongestionCauses of CongestionQueueing in router for particular outbound lineLost packets because of insufficient memoryToo much memory->long delays->timeoutsProcessors that are too slow for demandLines with insufficient capacity (bandwidth)NOTE: congestion control is an issue involving performance tuning of the entire subnet.

Flow control is between sender and receiver only


6-43

Resource Allocation TaxonomyRouter Centric vs Host Centric

Router or switch centric implies most work done by network nodes and they inform outside hosts how much traffic (if any) they are allowed to send.

Reservation vs Feed-backReservation means that end host requests and network nodes set aside resources or reject the call. Always coupled with router centric.Feed-back means hosts adjust their traffic depending on feedback received. Maybe be host centric or router centric.

Window vs Rate BasedWindow based like TCPRate based means host makes reservation for specific bandwidth (bps).


6-44

Example Congestion MetricsExample Congestion Metrics

Average queue lengthsPercent of packets discardedNumber of packets retransmittedAverage number of collisions (boadcast)Average packet delay (and standard deviation of delay)


6-45

Queue ServerArrivals Departures

Arrival Rate k Utlization

q

Scheduling discipline: FIFO or FCFS

Drop policy: Tail drop

These are prevalent in the Internet. Some routers add priority queuing, a separate queue that supports higher priority for control messages based on TOS field.


6-46

FAIR Queuing

FIFO queuing is unaware of different traffic flows (that could have different priority or QoS requirements). Fair queuing (FQ) is an algorithm based on maintaining separate queues for each flow currently being handled by router. Router then services these queues in round-robin.

When a given queue reaches a particular threshold, packets for that flow are discarded.Designed to complement other congestion control mechanisms.


6-47

W eighted Fair QueueingW eighted Fair QueueingProblem: hosts respond to choke packets voluntarily. Cooperating host gets penalized unfairly if others don't coorperate. Fair Queueing algorithm: at each output line router has separate queue corresponding to each source. Queues are serviced round-robin.

Still favors source that sends longer packets.Improvement: simulate byte-by-byte round robin.WFQ: then add weights according to source priority or bandwidth.


Congestion Control in Connectionless Networks

End-end congestion control:no explicit feedback from networkcongestion inferred from end-system observed loss, delayapproach taken by TCP

Network-assisted congestion control:routers provide feedback to end systems

single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)explicit rate sender should use

Two broad approaches towards congestion control:


Case study: ATM ABR congestion control

ABR: available bit rate:“elastic service” if sender’s path “underloaded”:

sender should use available bandwidth

if sender’s path congested:

sender throttled to minimum guaranteed rate

RM (resource management) cells:sent by sender, interspersed with data cellsbits in RM cell set by switches (“network-assisted”)

NI bit: no increase in rate (mild congestion)CI bit: congestion indication

RM cells returned to sender by receiver, with bits intact


Case study: ATM ABR congestion control

two-byte ER (explicit rate) field in RM cellcongested switch may lower ER value in cellsender’ send rate thus minimum supportable rate on path

EFCI bit in data cells: set to 1 in congested switchif data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell


TCP Congestion Controlend-end control (no network assistance)transmission rate limited by congestion window size, Congwin, over segments:

w segments, each with MSS bytes, sent in one RTT:

throughput = w * MSSRTT Bytes/sec

Congwin


TCP congestion control:

two “phases”slow start (exponential increase)congestion avoidance (linear increase)

• On timeout, threshold set to half congwin and congwin set to 1 MSS.

important variables:Congwinthreshold: defines threshold between two slow start phases.

“probing” for usable bandwidth:

ideally: transmit as fast as possible (Congwin as large as possible) without lossincrease Congwin until loss (congestion)loss: decrease Congwin, then begin probing (increasing) again


TCP Slowstart

exponential increase (per RTT) in window size (not so slow!)loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP)

initialize: Congwin = 1for (each segment ACKed)

Congwin++until (loss event OR

CongWin > threshold)

Slowstart algorithmHost A

RTT

Host B

time


TCP Congestion Avoidance

/* slowstart is over */ /* Congwin > threshold */Until (loss event) {every w segments ACKed:

Congwin++}

threshold = Congwin/2Congwin = 1perform slowstart

Congestion avoidance

1

1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs


6-55

TCP Fast Retransmit

The timeout adjustment mechanism previously studied proved to be overly conservative. Fast retransmit introduced to enable retransmission sooner than timer pops.

Upon receipt of 3rd Ack for a given packet, the sender concludes that packet is lost and retransmits. This usually happens quickly because of the cumulative nature of Acks.


6-56

TCP Fast Recovery

Idea is to avoid the “slow start” other than at the initial creation of the connection.When packet is lost, the window size is divided by 2 and then allowed to grow linearly. Thus, connection always operates in the additive increase range.

If packet is lost by “timeout”, then window size returns to 1.


TCP FairnessFairness goal: if N TCP

sessions share same bottleneck link, each should get 1/N of link capacity

TCP congestion avoidance:AIMD: additive increase, multiplicative decrease

increase window by 1 per RTTdecrease window by factor of 2 on loss event

AIMD

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2


Why is TCP fair?Two competing sessions:

Additive increase gives slope of 1, as throughout increasesmultiplicative decrease decreases throughput proportionally

R

R

equal bandwidth share

Connection 1 throughput

congestion avoidance: additive increaseloss: decrease window by factor of 2

congestion avoidance: additive increaseloss: decrease window by factor of 2


Why TCP Performance is Critical

Because of the importance of IP networks, TCP is the primary provider of end-to-end service.Network functions are often implemented in hardware while TCP is implemented in software.TCP is complex and interacts with many elements in the end-to-end path.TCP has total control over the transport of each byte of any TCP-based application.


Measures of TCP PerformanceDelay (round-trip or one-way)Maximum delayDelay variation or delay jitterPacket loss rateEffective throughput Throughput variationFile transfer timeFairness (refers to fair allocation of a resource, such as bandwidth)Resource consumption (CPU, memory, etc.)


Simple TCP ModelLet ( ) be a stochastic process that gives window size at time t 0.We continued to assume the AIMD model for this process. Thus, ( )increases linearly (up to a max of W) while no packets are lost i

W tW t≥

n the Wnetwork. When a packet is lost, we have ( ) and then a linear2

increase until max is again reached.

W t =

W2

W

Periodic saw-tooth function.


Model - continuedLet ( ) be the the packet transmission rate at time 0. Then the

( )common approximation is that ( ) . Note that this

assumes that increasing the transmission rate does NOT increase.

We als

X t tW tX tRTT

RTT

≥

=

o assume that there is a constant probability, , that any given packet is lost as it crosses the end-to-end connection. If is a random variable giving the number of packets transmitted between two

pL

[ ]

[ ]

1

lost packets, then has a geometric distribution and (1 ) , 1, 2,..., .

1Thus, .

kL P L k p p k

E Lp

−= = − = ∞

=


Model – continued (2)1Thus, is the expected number of packets transferred during a single

period of ( ). We now obtain this a second way.

Let be the length of the period and notice that the area under one period

is

pW t

T

1

W 1 W 1 W + W . This represents approximately2 2 2 2 2

which represents the period as being divided into intervals

of length during which the window is of size . Thus, the averag

n

k kk

k k

T T T

w T

T w=

⎛ ⎞= +⎜ ⎟⎝ ⎠

Δ

Δ

∑

i i

1

e 1 Wwindow size is W .2 2

nk

kk

TW wT=

Δ ⎛ ⎞= = +⎜ ⎟⎝ ⎠

∑


Model – continued (3)It follows that the average transmission rate is and the

average number of packets transmitted during one period is 1 WW . 2 2

Because the window increases by one for each round-trip

WXRTT

TXTRTT

=

⎛ ⎞= +⎜ ⎟⎝ ⎠

time W Wduring one period, we must have (W ) .2 2

1 W WThus, the above becomes W . We now set2 2 2

the two expressions for average packets transmitted to be equal:

1 W 1 and sol2 2 2

T RTT RTT

XT

WWp

= − =

⎛ ⎞= +⎜ ⎟⎝ ⎠

⎛ ⎞+ =⎜ ⎟⎝ ⎠

i

8ve for W .3p

=


Model – continued (4)

1

W2

We can now write an expression for the average sending rate of a TCP source as a function of the loss probability:

avg packets sent 1 3( ) .period length 2

This result is called the "inverse

pX pRTT RTT p

= = =i square-root p law."

It demonstrates that the transmission rate of a TCP source is inversely related to the round-trip time and the square-root of theaverage packet loss probability.


Example

What is the average sending rate of a TCP source if the average round-trip time is 350 ms and the probability that a packet is lost anywhere along the TCP connection is 0.02?

1 3Answer: 24.70.35 0.04

X = = pkts/sec.

Ref: M. Mathis, J. Semke, J. Mahdavi: The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm. ACM Computer Communications Review, July 1997.


The effect of errors on TCP

Whenever an error is detected in the lower layers, a packet is discarded. TCP assumes packet was lost because of network congestion.

Congestion window is reduced inappropriately.

This is particularly a problem today in wireless networks.


Effect of error rates (~2%)

Connection Bandwidth Measured Throughput

PercentAchieved

Single WLAN

1.5 Mbps 0.70 Mbps 47

WLAN + 15 Wired

Links

1.35 Mbps 0.31 Mbps 23

IEEE 802.11

2.0 Mbps 0.98 Mbps 49

IEEE 802.11b

11 Mbps 4.3 Mbps 39


Approaches to Improve TCP over Wireless Nets

Split TCP connections at gateways between wireless and wired links

Any retransmissions cross wireless connection only. Connections over wired links are unaware of losses.

Snooping inside TCP connectionsSnooping agent maintains buffer of TCP segments and maintains state.Segment resent locally before end-to-end TCP connection times out.

Explicit Loss Notification Can be sent by Snooping agent on loss unrelated to congestion.Requires use of ELN bit in TCP header.


Summary

principles behind transport layer services:

multiplexing/demultiplexingreliable data transferflow controlcongestion controlfairness

instantiation and implementation in the Internet

UDPTCP


6-71

Congestion Control in Connection Oriented (or VC) Networks


6-72

Congestion Control PrinciplesCongestion Control PrinciplesOpen Loop

Prevent problems by good designWhen does net accept new traffic?When does net discard packets?Which packets get prioritized?

Closed Loop Monitor/detect congestion in networkPass congestion info to where action can be taken (feedback loop)Adjust operation to correct(react) to problem.

GOOD ARCHITECTURES often use both approaches.


6-73

Admission ControlAdmission Control

Open Loop VersionUse flowspec parameters to assign resources to every VC admitted to the network. Once all resources have been committed, reject further connections.

Closed Loop VersionWhen a certain level of congestion has been measured and feedback given to entry nodes of network, reject further connections.


6-74

Feedback TechniquesFeedback Techniques

Router detects congestion (from queues or otherwise) and sends information to source.

Info can also be collected with probe packets.Which source? How quickly to react? Note that this control traffic increases the load precisely when network already in trouble.

Bit/bits can be reserved in each header


6-75

W hen congestions occurs...W hen congestions occurs...

Increase resourcesBring up additonal (dial-up) linesBring up additional routers/switchesDedicate more bandwidth on existing linesSplit traffic along multiples routes

Decrease loadDon't allow additional usersRemove users with lower priorityGive some/all users less bandwidth


6-76

Policies that Affect CongestionPolicies that Affect Congestion


6-77

Quality of Service

We have previously seen that ATM, for example, supports several service classes: CBR, VBR, ABR, UBR and that each is designed for particular types of applications:

Including real-time applications…Defn. Networks that support such different levels of service are said to support quality of service (QoS).


6-78

Real-time Audio Example

Samples of analog audio are collected and digitized using an A->D converter.Typically one sample collected eachTo sound accurate they must be played out at the receiving end at exactly this rate. Regardless of packet network architecture, it is not possible to guarantee exact interarrivals. This is handled through use of a “playback buffer.”

125 .sμ


6-79

Approaches to QoS Support

Fine-grained approaches provide QoS to individual applications or flows.

Integrated Services from IETF (associated with RSVP).ATM when supporting QoS to applications

Coarse-grained approaches provide QoS to large classes of data or to aggregated traffic.

Differentiated Services (IETF)ATM when used for aggregated backbone traffic.


6-80

Integrated Services: Classes

IETF defined service classes and a protocol to support them (RSVP) in 1995-1997.Guaranteed QOS: this class is provided with firm bounds on queuing delay at a router; envisioned for hard real-time applications that are highly sensitive to end-to-end delay expectation and variance.Controlled Load: this class is provided a QOS closely approximating that provided by an unloaded router; envisioned for today’s IP network real-time applications which perform well in an unloaded network


6-81

Integrated Services Mechanisms

To get specific service must describe the traffic to be submitted and must request the particular service characteristics:

Flowspec includes TSpec and RspecFor guaranteed QoS the source’s traffic characterization is essentially given by a “token bucket” with parameters (q,C) and the requested service by a (max) packet transmission rate, M.

C is bucket capacity (bytes)q is token arrival rate (bytes/sec) M max output rate


6-82

Traffic ShapingTraffic ShapingReduces impact of "bursty" traffic on network by regulating average RATE.Usually occurs in virtual circuit networks like ATM.User and subnet agree on traffic characteristics for particular VC

Eg. average burst length, max burst length, average rate

Subnet monitors VC and discards its traffic when agreement violated (if network is congested).

called "traffic policing"


6-83

Leaky Bucket Algorithm (1986)Leaky Bucket Algorithm (1986)

Example: 1MBytes arrivein 40 msec burst each sec.

Example: output rate is 2 MBytes/sec steady or1MByte in 500 msec.

Allows ONLY steady output rate with bursty input.


6-84

Token Bucket AlgorithmToken Bucket AlgorithmAllows limited burstiness up to max depth of token bucket.

Note: in both leaky bucket and tokenbucket versions a variation is possiblein which a specific number of bytes isauthorized as output per token (or per second) instead of one packet orcell. Useful with variable packet length traffic.


6-85

Choose best available end-to-end routeReserve required bandwidthSmooth input bursts ("rate-based")Adjust bandwidth as neededDiscard packets if necessary

Congestion control...


6-86

- guarantee loss requirements- use network resources efficiently

time

bit rate peak

rate

average rate

equivalent capacity

20-50% savings

Bandwidth allocation

R = Peak Ratem = Mean Rateb = Mean Burst Length

EC

eps

Equivalent Capacity = the amount of bandwidth to guarantee that CLR is below a given maximum eps. A function of:

R, m , b Buffer size, X Maximum CLR, epsX

EC = the size of opening to guarantee that overflow ratio is below a given maximum eps.Fluid

model


6-87

Max Burst Length for Token Bucket AlgorithmMax Burst Length for Token Bucket Algorithm

First thought: it is just max data corresponding to max tokens (bucket depth)/output transmission rate.

Example: 1Mbyte/(25MByte/sec) = 40 msecWRONG because more tokens arrive as data transmitted.

Let S=burst length (secs). Let C=bucket capacity (bytes). Let q=token arrival rate (bytes/sec). Let M=peak output rate bytes/sec.

Output burst contains C+qS bytes until bucket is empty.Also, whatever S equals, there are MS bytes in the max burst.Implies C+qS = MS so S = C/(M-q).


6-88

Exam pleExam ple

A token bucket supports a network of OC3 connections. Max capacity of the bucket is 100 megabits and the bucket is filled at a rate of 10 mbps. W hat is the max burst length (in bits)?

6

6 6

6

100 10 sec 690155 10 10 10

0.69(155 10 ) 106.96 megabits.

CS msM q

MaxBurstBits

×= = =

− × − ×

= × =

• Note also that the worst-case delay for a packet regulated by a token bucket is C/M provided q<M.


6-89

Integrated Services Mechanisms-Returning

To get specific service must describe the traffic to be submitted and must request the particular service characteristics:

Flowspec includes TSpec and RspecFor guaranteed QoS the source’s traffic characterization is essentially given by a “token bucket” with parameters (q,C) and the requested service by a (max) packet transmission rate, M.


6-90

Flow SpecificationFlow Specification

For this to work sender, subnet, receiver must agree to traffic parameters as described in a flow spec.

describes characteristics of injected trafficdescribes the desired quality of service.Source describes its traffic and desired QoS to subnet. Subnet may accept or negotiate or reject. If successful, source then works with receiver to get same agreement.


6-91

Resource Reservation Protocol (RSVP)

Signaling protocol but designed to operate on top of the connectionless IP networks.

Supports multicast.Idea: client requests to participate in a multicast group, say, to receive a movie. The multicast tree is build with “sender” at the root. Sender sends TSpec to receiver (or client).

In a PATH message.Receiver gets PATH message and sends RESV message back to sender with sender Tspec and receiver Rspec.

Each router along the path decides to accept or reject.


6-92

Maintaining the “connection”Receiver sends RESV message each 30 secs.If RESV messages stop coming, then routers simply free-up their resources:

“soft state”If routes change, receiver is notified with new PATH message, and sends next RESV message along the new path. Multicast support: New RESV requests can be aggregated and Tspec’s may specify, for example, enough resources for k of n speakers.


6-93

Int Svcs: Controlled Load

Intent is to guarantee service that approximates lightly loaded router.

Traffic is simply requested to be part of controlled load.Weighted Fair Queueing (WFQ) used to separate controlled load traffic from other.Admission control used to guarantee service levels.


6-94

Scalability of Integrated Services

RSVP may require that each flow passing through a router have a reservation.

Notice there can be 39,000 kbps audio streams in a single OC-48 connection. Information needs to be refreshed.Router must classify, police, and manage queues for each flow.Admission control decisions must be made…

Many ISPs avoid because of complexity.


6-95

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


6-96

Differentiated Services

Approach: Only simple functions in the core, and relatively complex functions at edge routers (or hosts)Do not define service classes, instead provides functional components with which service classes can be built

Bottom Line: Integrated and Differentiated Services are Rarely Used

end to end protocolsmy.fit.edu/~gmarin/cse5231/oldtransportlayersect5.pdftransport-layer protocols....

Documents