slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
End to End Protocols PowerPoint Presentation
Download Presentation
End to End Protocols

Loading in 2 Seconds...

play fullscreen
1 / 47

End to End Protocols - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

End to End Protocols. End to End Protocols. Last week: basic protocols Stop & wait (Correct but low performance) Today: Window based protocol. Go Back N Selective Repeat TCP protocol. UDP protocol. Next week: Flow control & congestion control. rdt3.0: Stop-and-Wait Operation.

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 'End to End Protocols' - zan


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
slide1

End to End

Protocols

end to end protocols
End to End Protocols
  • Last week:
    • basic protocols
    • Stop & wait (Correct but low performance)
  • Today:
    • Window based protocol.
      • Go Back N
      • Selective Repeat
    • TCP protocol.
    • UDP protocol.
  • Next week: Flow control & congestion control
slide3

rdt3.0: Stop-and-Wait Operation

  • rdt3.0 works, but performance stinks
  • example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

sender

receiver

first packet bit transmitted, t = 0

last packet bit transmitted, t = L / R

first packet bit arrives

RTT

last packet bit arrives, send ACK

ACK arrives, send next

packet, t = RTT + L / R

last week performance of rdt3 0
rdt3.0 works, but performance stinks

example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

fraction of time

sender busy sending

=

= 0.00027

Utilization = U =

8kb/pkt

T

=

8 microsec

= 8 microsec

transmit

10**9 b/sec

30.016 msec

Last week: Performance of rdt3.0
  • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
  • transport protocol limits use of physical resources!
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

Pipelined protocols
go back n
Sender:

k-bit seq # in pkt header

Unbounded seq. num.

“window” of up to N, consecutive unack’ed pkts allowed

Go-Back-N
  • ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
    • may deceive duplicate ACKs (see receiver)
  • timer for the packet at base
  • timeout(n): retransmit pkt n and all higher seq # pkts in window
gbn sender extended fsm
GBN: sender extended FSM

/*for the packet at the new base*/

gbn receiver extended fsm
receiver simple:

ACK-only: always send ACK for correctly-received pkt with highest in-order seq #

may generate duplicate ACKs

need only remember expectedseqnum

out-of-order pkt:

discard (don’t buffer) -> no receiver buffering!

ACK pkt with highest in-order seq #

GBN: receiver extended FSM

expectedseqnum=expectedseqnum+1

gbn in action
GBN inaction

window

size = 4

gbn correctness
GBN: Correctness
  • Claim I (safety):
    • The receiver outputs the data in the correct order
    • Proof: unbounded seq. num. QED
  • Claim I (seqnum):
    • In the receiver:
      • Value of expectedseqnum only increases
    • In the sender:
      • The received ACK seqnum only increases.
    • This is why the sender does not need to test getacknum(rcvpkt) when updating variable base!
gbn correctness liveness
GBN: correctness - liveness
  • Let:
    • base=k; expecetdseqnum=m; nextseqnum=n;
  • Observation: k ≤ m ≤ n
  • Claim (Liveness):
    • If k<m then eventually base ≥ m
    • If (k=m and m<n) then eventually:
      • receiver outputs data item m
      • Expectedseqnum ≥ m+1
gbn bounding seq num

Ack i<k

Seq num only increases

Ack i<k

Ack k

impossible

impossible

Data i<k-N

Data k

Data i<k-N

Not in window with k

GBN - Bounding seq. num.

Claim: After receiving Data k no Data i<k-N is received.

After receiving ACK k no ACK i<k is received.

Clearing a FIFO channel:

Corollary: Sufficient to use N+1 seq. num.

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

again limits seq #s of sent, unACKed pkts

sender timer for each unACKed pkt

Selective Repeat
selective repeat17
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 #

receiver

sender

Selective repeat

pkt 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
selective repeat correctness
Selective Repeat - Correctness
  • Infinite seq. Num.
    • Safety: immediate from the seq. Num.
    • Liveness: Eventually data and ACKs get through.
  • Finite Seq. Num.
    • Idea: Re-use seq. Num.
    • Use less bits to encode them.
  • Number of seq. Num.:
    • At least N.
    • Needs more!
selective repeat dilemma
Example:

seq #’s: 0, 1, 2, 3

window size=3

receiver sees no difference in two scenarios!

Incorrectly

Passes duplicate data as new in (a) or

Discards in (b)

Q: what relationship between seq # size and window size?

Selective repeat: dilemma
choosing the window size
Choosing the window size
  • Small window size:
    • idle link (under-utilization).
  • Large window size:
    • Buffer space
    • Delay after loss
  • Ideal window size (assuming very low loss)
    • RTT =Round trip time
    • C = link capacity
    • window size = RTT * C
  • What happens with no loss?
slide22

End to End

Protocols:

Multiplexing &

Demultiplexing

multiplexing demultiplexing
Recall: segment - unit of data exchanged between transport layer entities

aka TPDU: transport protocol data unit

M

M

M

M

application

transport

network

application

transport

network

application

transport

network

H

n

Multiplexing/demultiplexing

Demultiplexing: delivering

received segments to

correct app layer processes

receiver

P3

P4

application-layer

data

segment

header

P1

P2

segment

H

t

M

segment

multiplexing demultiplexing24
multiplexing/demultiplexing:

based on sender, receiver port numbers, IP addresses

source, dest port #s in each segment

recall: well-known port numbers for specific applications

Using IP addresses – layer violation.

Multiplexing:

Multiplexing/demultiplexing

gathering data from multiple

app processes, enveloping

data with header (later used

for demultiplexing)

32 bits

source port #

dest port #

other header fields

application

data

(message)

TCP/UDP segment format

multiplexing demultiplexing examples

Source IP: C

Dest IP: B

source port: x

dest. port: 80

Source IP: C

Dest IP: B

source port: y

dest. port: 80

Source IP: A

Dest IP: B

source port: x

dest. port: 80

source port:23

dest. port: x

source port: x

dest. port: 23

Multiplexing/demultiplexing: examples

Web client

host C

server B

host A

port use: simple telnet app

Web

server B

Web client

host A

port use: Web server

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 application

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

UDP: User Datagram Protocol [RFC 768]
udp more
often used for streaming multimedia apps

loss tolerant

rate sensitive

other UDP uses (why?):

DNS

SNMP

reliable transfer over UDP: add reliability at application layer

application-specific error recover!

UDP: more

32 bits

source port #

dest port #

Length, in

bytes of UDP

segment,

including

header

checksum

length

Application

data

(message)

UDP segment format

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.

UDP checksum

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

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
tcp segment structure

32 bits

source port #

dest port #

sequence number

acknowledgement number

head

len

not

used

rcvr window size

U

A

P

R

S

F

checksum

ptr urgent data

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

PSH: push data now

(generally not used)

# bytes

rcvr willing

to accept

RST, SYN, FIN:

connection estab

(setup, teardown

commands)

Internet

checksum

(as in UDP)

connection management objective
Connection Management: Objective

Agree on initial sequence numbers

a sender will not reuse a seq# before it is sure that all packets with the seq# are purged from the network

the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet

To avoid waiting for the seq# to start a session, use a larger seq# space

needs connection setup so that the sender tells the receiver initial seq#

Agree on other initial parameters

33

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

Q: how receiver handles out-of-order segments

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

time

TCP seq. #’s and ACKs

Host B

Host A

User

types

‘C’

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

host ACKs

receipt of

‘C’, echoes

back ‘C’

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

host ACKs

receipt

of echoed

‘C’

Seq=43, ACK=80

simple telnet scenario

three way handshake twh tomlinson 1975
Three Way Handshake (TWH) [Tomlinson 1975]

To ensure that the other side does want to send a request

Host A

Host B

REJECT(seq=y)

DATA(seq=x+1)

SYN(seq=x)

ACK(seq=z)

SYN(seq=x)

ACK(seq=y)

accept?

ACK(seq=x), SYN(seq=y)

ACK(seq=x), SYN(seq=y)

no suchrequest

reject

Host A

Host B

35

connection close
Connection Close

Objective of closure handshake:

each side can release resource and remove state about the connection

I am done. Are you done too?

client

server

init. close

release

resource?

close

release

resource?

I am done too. Goodbye!

close

release

resource?

36

tcp reliable data transfer
TCP: reliable data transfer

event: data received

from application above

simplified sender, assuming

  • one way data transfer
  • no flow, congestion control

create, send segment

wait

for

event

event: timer timeout for

segment with seq # y

wait

for

event

retransmit segment

event: ACK received,

with ACK # y

ACK processing

tcp reliable data transfer38
TCP: reliable data transfer

00sendbase = initial_sequence number

01 nextseqnum = initial_sequence number

02

03 loop (forever) {

04 switch(event)

05 event:data received from application above

06 create TCP segment with sequence number nextseqnum

07 start timer for segment nextseqnum

08 pass segment to IP

09 nextseqnum = nextseqnum + length(data)

10 event:timer timeout for segment with sequence number y

11 retransmit segment with sequence number y

12 compue new timeout interval for segment y

13 restart timer for sequence number y

14 event:ACK received, with ACK field value of y

15 if (y > sendbase) { /* cumulative ACK of all data up to y */

16 cancel all timers for segments with sequence numbers < y

17 sendbase = y

18 }

19 else { /* a duplicate ACK for already ACKed segment */

20 increment number of duplicate ACKs received for y

21 if (number of duplicate ACKS received for y == 3) {

22 /* TCP fast retransmit */

23 resend segment with sequence number y

24 restart timer for segment y

25 }

26 } /* end of loop forever */

Simplified

TCP

sender

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

immediately send single

cumulative ACK

send duplicate ACK, indicating seq. #

of next expected byte

immediate ACK if segment starts

at lower end of gap

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 arrival

higher-than-expect seq. #

gap detected

arrival of segment that

partially or completely fills gap

tcp retransmission scenarios

Host A

Host B

Seq=92, 8 bytes data

ACK=100

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

Seq=92 timeout

ACK=100

ACK=120

Seq=100 timeout

Seq=92, 8 bytes data

ACK=120

premature timeout,

cumulative ACKs

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

server: contacted by client

TCP Connection Management
tcp connection management cont
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 SYN-ACK control segment

ACKs received SYN

allocates buffers

specifies server-> receiver initial seq. #

Step 3:client receives SYN-ACK and replies with ACK (possibly with data).

TCP Connection Management (cont.)

client

server

Syn seq=100

SYN_sent

SYN-ACK seq=330 ack=100

SYN_rcvd

ACK

ESTABLISHED

ESTABLISHED

tcp connection management cont43
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

FIN

ACK

close

FIN

ACK

timed wait

closed

TCP Connection Management (cont.)
tcp connection management cont44
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.

TCP Connection Management (cont.)

client

server

closing

FIN

ACK

closing

FIN

ACK

timed wait

closed

closed

tcp connection management cont45
TCP Connection Management (cont)

TCP server

lifecycle

TCP client

lifecycle

slide46

TCP

state

transition

diagram

simultaneous open

SYN

Seq=100

SYN-ACK

Seq=331

Ack=100

SYN-ACK

Seq=101

Ack=330

SYN_RCVD

Simultaneous open

SYN_SENT

SYN

Seq=330

ESTABLISHED

ACK+Data

ACK+Data