chapter 3 outline l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 3 outline PowerPoint Presentation
Download Presentation
Chapter 3 outline

Loading in 2 Seconds...

play fullscreen
1 / 48

Chapter 3 outline - PowerPoint PPT Presentation


  • 168 Views
  • Uploaded on

3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer. 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 3 outline' - duff


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 3 outline
3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP

segment structure

reliable data transfer

flow control

connection management

3.6 Principles of congestion control

3.7 TCP congestion control

Chapter 3 outline

Transport Layer

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

TCP: OverviewRFCs: 793, 1122, 1323, 2018, 2581

Transport Layer

tcp segment structure

32 bits

source port #

dest port #

sequence number

acknowledgement number

head

len

not

used

Receive window

U

A

P

R

S

F

checksum

Urg data pnter

Options (variable length)

application

data

(variable length)

TCP segment structure

URG: urgent data

(generally not used)

counting

by bytes

of data

(not segments!)

ACK: ACK #

valid

# bytes

rcvr willing

to accept

PSH: push data now

RST, SYN, FIN:

connection estab

(setup, teardown

commands)

Internet

checksum

(as in UDP)

Transport Layer

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

In Rdt x.x protocols, the ack seq# is the current received one

cumulative ACK

different from Selective Repeat

Q: how receiver handles out-of-order segments?

A: TCP spec doesn’t say

Practical approach: save in buffer

Q: How TCP implement duplex communication?

Seq. # for sending data, Ack# for receiving data

TCP seq. #’s and ACKs

Transport Layer

an example

time

An example

Host B

Host A

User

79

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

42

host ACKs

receipt, echoes

back ‘pass’

Seq=79, ACK=46, data = ‘pass’

host ACKs

receipt, send

back use

password

Seq=46, ACK=83 data =‘cda4527’

Sequence number is

based on bytes, not packets

simple telnet scenario

Transport Layer

tcp round trip time and timeout
Q: how to set TCP timeout value?

longer than RTT

but RTT varies

too 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

SampleRTT will vary, want estimated RTT “smoother”

average several recent measurements, not just current SampleRTT

TCP Round Trip Time and Timeout

Transport Layer

tcp round trip time and timeout7
TCP Round Trip Time and Timeout
  • Exponential weighted moving average
  • influence of past sample decreases exponentially fast
  • typical value:  = 0.125 [RFC 2988]

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

Transport Layer

tcp round trip time and timeout9
Setting the timeout

EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin

first estimate of how much SampleRTT deviates from EstimatedRTT:

TCP Round Trip Time and Timeout

DevRTT = (1-)*DevRTT +

*|SampleRTT-EstimatedRTT|

(typically,  = 0.25) [RFC 2988]

Then set timeout interval:

TimeoutInterval = EstimatedRTT + 4*DevRTT

Transport Layer

chapter 3 outline10
3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP

segment structure

reliable data transfer

flow control

connection management

3.6 Principles of congestion control

3.7 TCP congestion control

Chapter 3 outline

Transport Layer

tcp reliable data transfer
TCP creates rdt service on top of IP’s unreliable service

Pipelined segments

Cumulative acks

Similar to GBN

TCP uses single retransmission timer

Similar to GBN

Remove the timer management overhead

Out of order packets

Not specified

Usually buffered

Similar to SR

Retransmissions are triggered by:

timeout events

duplicate acks

TCP reliable data transfer

Transport Layer

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

Not Go Back all N segments

restart timer

Ack rcvd:

If acknowledges previously unacked segments

update what is known to be acked

start timer if there are outstanding segments (since cumulative acks)

Similar to GBN

TCP sender events:

Transport Layer

tcp sender simplified

NextSeqNum = InitialSeqNum

SendBase = InitialSeqNum

loop (forever) {

switch(event)

event: data received from application above

create TCP segment with sequence number NextSeqNum

if (timer currently not running)

start timer

pass segment to IP

NextSeqNum = NextSeqNum + length(data)

event: timer timeout

retransmit not-yet-acknowledged segment with

smallest sequence number

start timer

event: ACK received, with ACK field value of y

if (y > SendBase) {

SendBase = y

if (there are currently not-yet-acknowledged segments)

start timer

}

} /* end of loop forever */

TCP sender(simplified)
  • Comment:
  • One direction only
  • SendBase-1: last
  • cumulatively ack’ed byte
  • Example:
  • SendBase-1 = 71;y= 73, so the rcvrwants 73+ ;y > SendBase, sothat new data is acked

Transport Layer

tcp retransmission scenarios

Host A

Host B

Seq=92, 8 bytes data

ACK=100

Seq=92 timeout

timeout

X

loss

Seq=92, 8 bytes data

ACK=100

time

time

lost ACK scenario

TCP: retransmission scenarios

Host A

Host B

Seq=92, 8 bytes data

Seq=100, 20 bytes data

ACK=100

ACK=120

Seq=92, 8 bytes data

Sendbase

= 100

SendBase

= 120

ACK=120

Seq=92 timeout

SendBase

= 100

SendBase

= 120

premature timeout

Transport Layer

tcp retransmission scenarios more

Host A

Host B

Seq=92, 8 bytes data

ACK=100

Seq=92 timeout

Seq=100, 20 bytes data

timeout

X

loss

ACK=120

time

time

Cumulative ACK scenario

TCP retransmission scenarios (more)

Host A

Host B

Seq=92, 8 bytes data

Seq=100, 20 bytes data

ACK=100

ACK=120

Seq=92, 8 bytes data

Sendbase

= 100

SendBase

= 120

SendBase

= 120

ACK=120

Seq=92 timeout

SendBase

= 120

premature timeout

Double Timeout method in run time

Transport Layer

tcp ack generation rfc 1122 rfc 2581
TCP ACK generation[RFC 1122, RFC 2581]

TCP Receiver action

Delayed ACK. Wait up to 500ms

for next segment. If no next segment,

send ACK (why?)

Immediately send single cumulative

ACK, ACKing both in-order segments

Immediately send duplicate ACK,

indicating seq. # of next expected byte

Immediate send ACK, provided that

segment starts at lower end of gap

Event at Receiver

Arrival of in-order segment with

expected seq #. All data up to

expected seq # already ACKed

Arrival of in-order segment with

expected seq #. One other

segment has ACK pending

Arrival of out-of-order segment

higher-than-expect seq. # .

Gap detected

Arrival of segment that

partially or completely fills gap

Transport Layer

fast retransmit
Retransmission triggered by timeout

Time-out period often relatively long:

long delay before resending lost packet

Detect lost segments via duplicate ACKs.

Sender often sends many segments back-to-back (pipelining)

If segment is lost, there will likely be many duplicate ACKs.

If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost:

fast retransmit:resend segment before timer expires

Fast Retransmit

Transport Layer

fast retransmit algorithm
Fast retransmit algorithm:

event: ACK received, with ACK field value of y

if (y > SendBase) {

SendBase = y

if (there are currently not-yet-acknowledged segments)

start timer

}

else {

increment count of dup ACKs received for y

if (count of dup ACKs received for y = 3) {

resend segment with sequence number y

}

a duplicate ACK for

already ACKed segment

Y == SendBase (why?)

fast retransmit

Transport Layer

chapter 3 outline19
3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP

segment structure

reliable data transfer

flow control

connection management

3.6 Principles of congestion control

3.7 TCP congestion control

Chapter 3 outline

Transport Layer

tcp gbn or sr
TCP: GBN or SR?
  • Cumulative Acks --- GBN
  • Buffer out-of-order packets --- SR
  • Retransmit current BaseSeq only when timeout --- SR
  • TCP: a hybrid protocol
    • ACK #: not packet number, but byte number
    • ACK #: expected (not like rdt x.x)

Transport Layer

tcp flow control
receive side of TCP connection has a receive buffer:

speed-matching service: matching the send rate to the receiving app’s drain rate

flow control

sender won’t overflow

receiver’s buffer by

transmitting too much,

too fast

TCP Flow Control
  • app process may be slow at reading from buffer

Transport Layer

tcp flow control how it works
(Suppose TCP receiver discards out-of-order segments)

spare room in buffer

= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in TCP header

Sender limits unACKed data to RcvWindow

guarantees receive buffer doesn’t overflow

TCP Flow control: how it works

Transport Layer

chapter 3 outline23
3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP

segment structure

reliable data transfer

flow control

connection management

3.6 Principles of congestion control

3.7 TCP congestion control

Chapter 3 outline

Transport Layer

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

initialize TCP variables:

seq. #s

Why not always 0?

No confusion

Security

buffers, flow control info (e.g. RcvWindow)

client: connection initiator

connect();

server: contacted by client

accept();

TCP Connection Management

Transport Layer

tcp connection setup three way handshaking
TCP Connection Setup --- Three-Way Handshaking

Step 1:client host sends TCP SYN segment to server

  • specifies initial seq #
  • no data

Step 2:server host receives SYN, replies with SYN/ACK segment

  • server allocates buffers
  • specifies server initial seq. #

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

Ethereal Example

client

server

SYN,

seq=client_seq

SYN/ACK,

seq=server_seq, ack=client_seq+1

ACK,

seq=client_seq+1

ack=server_seq+1

Transport Layer

tcp connection management cont
Closing a connection:

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

FIN

ACK

close

FIN

ACK

timed wait

closed

TCP Connection Management (cont.)

Transport Layer

tcp connection management cont27
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.

TCP Connection Management (cont.)

client

server

closing

FIN

ACK

closing

FIN

ACK

Some applications simply send RST to terminate TCP connections immediately

timed wait

closed

closed

Ethereal Example

Transport Layer

chapter 3 outline28
3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP

segment structure

reliable data transfer

flow control

connection management

3.6Principles of congestion control

3.7 TCP congestion control

Chapter 3 outline

Transport Layer

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!

Principles of Congestion Control

Transport Layer

causes costs of congestion scenario 1
two senders, two receivers

one router, infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

Host A

Host B

Causes/costs of congestion: scenario 1

lout

lin : original data

unlimited shared output link buffers

Remember the queue delay formula?

Transport Layer

causes costs of congestion scenario 2
one router, finite buffers

sender retransmission of lost packet

Causes/costs of congestion: scenario 2

Host A

lout

lin: original data

l'in: original data, plus retransmitted data

Host B

finite shared output link buffers

Transport Layer

causes costs of congestion scenario 232
Always want : (goodput)

“perfect” retransmission only when loss:

retransmission of delayed (not lost) packet makes larger (than perfect case) for same

l

l

l

>

=

l

l

l

R/2

in

in

in

R/2

R/2

out

out

out

R/3

lout

lout

lout

R/4

R/2

R/2

R/2

lin

lin

lin

a.

b.

c.

Causes/costs of congestion: scenario 2

If every packet

forwarded twice

“costs” of congestion:

  • more work (retrans) for given “goodput”
  • unneeded retransmissions: link carries multiple copies of pkt

Transport Layer

causes costs of congestion scenario 3
four senders

multihop paths

timeout/retransmit

l

l

in

in

Host A

Host B

Causes/costs of congestion: scenario 3

Q:what happens as and increase ?

lout

lin : original data

l'in : original data, plus retransmitted data

finite shared output link buffers

Transport Layer

causes costs of congestion scenario 334

Host A

Host B

Causes/costs of congestion: scenario 3

lout

Another “cost” of congestion:

  • when packet dropped, any “upstream” transmission capacity used for that packet was wasted!

Transport Layer

approaches towards congestion control
End-end congestion control:

no explicit feedback from network

congestion inferred from end-system observed loss, delay

approach 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 send at

Approaches towards congestion control

Two broad approaches towards congestion control:

Transport Layer

chapter 3 outline36
3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP

segment structure

reliable data transfer

flow control

connection management

3.6 Principles of congestion control

3.7 TCP congestion control

Chapter 3 outline

Transport Layer

tcp congestion control
end-end control (no network assistance)

sender limits transmission:

LastByteSent-LastByteAcked

 CongWin

Roughly,

Why this formula?

CongWin is dynamic, function of perceived network congestion

How does sender perceive congestion?

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

three mechanisms:

AIMD

slow start

conservative after timeout events

CongWin

rate =

Bytes/sec

RTT

TCP Congestion Control

Transport Layer

tcp aimd
multiplicative decrease: cut CongWin in half after loss eventTCP AIMD

additive increase: increase CongWin by 1 MSS every RTT in the absence of loss events: probing

MSS: Maximum Segment Size

Long-lived TCP connection

Transport Layer

tcp slow start
When connection begins, CongWin = 1 MSS

Example: MSS = 500 bytes & RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be >> MSS/RTT

desirable to quickly ramp up to respectable rate

TCP Slow Start
  • When connection begins, increase rate exponentially fast until first loss event

Transport Layer

tcp slow start more
When connection begins, increase rate exponentially until first loss event:

doubleCongWin every RTT

done by incrementing CongWin for every ACKed segment

Summary: initial rate is slow but ramps up exponentially fast

time

TCP Slow Start (more)

Host A

Host B

one segment

RTT

two segments

four segments

Transport Layer

refinement more
Q: When should the exponential increase switch to linear?

A: When CongWin gets to 1/2 of its value before timeout.

Implementation:

Variable Threshold

At loss event, Threshold is set to 1/2 of CongWin just before loss event

Refinement (more)

Transport Layer

refinement
After 3 dup ACKs:

CongWin is cut in half

window then grows linearly

But after timeout event:

CongWin instead set to 1 MSS;

window then grows exponentially

to a threshold, then grows linearly

Refinement

Philosophy:

  • 3 dup ACKs indicates network capable of delivering some segments
  • timeout before 3 dup ACKs is “more alarming”

Transport Layer

summary tcp congestion control
Summary: TCP Congestion Control
  • When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
  • When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
  • When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
  • When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

Transport Layer

tcp fairness
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K

TCP connection 1

bottleneck

router

capacity R

TCP

connection 2

TCP Fairness

Transport Layer

why is tcp fair
Two competing sessions:

Additive increase gives slope of 1, as throughout increases

multiplicative decrease decreases throughput proportionally

Why is TCP fair?

equal bandwidth share

R

loss: decrease window by factor of 2

congestion avoidance: additive increase

Connection 2 throughput

loss: decrease window by factor of 2

congestion avoidance: additive increase

Connection 1 throughput

R

Transport Layer

fairness more
Fairness and UDP

Multimedia apps often do not use TCP

do not want rate throttled by congestion control

Instead use UDP:

pump audio/video at constant rate, tolerate packet loss

Research area: TCP friendly

Fairness and parallel TCP connections

nothing prevents app from opening parallel cnctions between 2 hosts.

Web browsers do this

Example: link of rate R supporting 9 cnctions;

new app asks for 1 TCP, gets rate R/10

new app asks for 9 TCPs, gets R/2 !

Fairness (more)

Transport Layer

chapter 3 summary
principles behind transport layer services:

multiplexing, demultiplexing

reliable data transfer

flow control

congestion control

instantiation and implementation in the Internet

UDP

TCP

Next:

leaving the network “edge” (application, transport layers)

into the network “core”

Chapter 3: Summary

Transport Layer