EEC-484/584 Computer Networks

EEC-484/584EEC-484/584Computer Computer NetworksNetworksLecture 7Lecture 7

Wenbing ZhaoWenbing Zhao

[email protected] [email protected] (Part of the slides are based on Drs. Kurose & Ross(Part of the slides are based on Drs. Kurose & Ross’’s slides s slides for their for their Computer Networking Computer Networking book)book)

04/19/2304/19/23 EEC-484/584: Computer NetworksEEC-484/584: Computer Networks

OutlineOutline Reminder:

No class next Monday (Columbus Day) Reliable data transfer Pipelining protocols UDP TCP (part I)


rdt2.1: sender handles garbled rdt2.1: sender handles garbled ACK/NAKsACK/NAKs

Wait for call 0 from

above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or NAK 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )


rdt_send(data)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)


above

Wait for ACK or NAK 1

Wenbing ZhaoWenbing Zhao04/19/2304/19/23 EEC-484/584: Computer NetworksEEC-484/584: Computer Networks

rdt2.1: receiver handles rdt2.1: receiver handles garbled garbled packetspackets

Wait for 0 from below

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)


rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)


rdt2.1: discussionrdt2.1: discussionSender: seq # added to pkt two seq. #’s (0,1) will

suffice. Why? must check if received

ACK/NAK corrupted twice as many states

state must “remember” whether “current” pkt has 0 or 1 seq. #

Receiver: must check if received

packet is duplicate state indicates whether 0 or

1 is expected pkt seq # note: receiver can not know

if its last ACK/NAK received OK at sender


rdt2.2: a NAK-free rdt2.2: a NAK-free protocolprotocol Same functionality as rdt2.1, using acks only Instead of NAK, receiver sends ACK for last pkt received

OK Receiver must explicitly include seq # of pkt being acked

Duplicate ACK at sender results in same action as NAK: retransmit current pkt


rdt2.2: sender, receiver rdt2.2: sender, receiver fragmentsfragments


above


rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

Wait for ACK

0

sender FSMfragment


rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

receiver FSMfragment


rdt3.0: channels with rdt3.0: channels with errors errors andand loss lossNew assumption: underlying

channel can also lose packets (data or acks) Checksum, seq. #, Acks,

retransmissions will be of help, but not enough

Approach: sender waits “reasonable” amount of time for ACK

Retransmits if no ACK received in this time

If pkt (or ACK) just delayed (not lost): Retransmission will be

duplicate, but use of seq. #’S already handles this

Receiver must specify seq # of pkt being acked

Requires countdown timer


rdt3.0 rdt3.0 sendersender

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for

ACK0

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )


above

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)


rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )


stop_timer

stop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

Wait for call 0from

above

Wait for

ACK1

rdt_rcv(rcvpkt)


rdt3.0 in actionrdt3.0 in action


rdt3.0 in actionrdt3.0 in action


Performance of rdt3.0Performance of rdt3.0 rdt3.0 works, but performance stinks ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:

U sender: utilization – fraction of time sender busy sending

U sender

= .008

30.008 = 0.00027

microseconds

L / R

RTT + L / R =

1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link network protocol limits use of physical resources!

dsmicrosecon8bps10

bits80009

R

Ldtrans


EEC-484/584: Computer NetworksEEC-484/584: Computer Networks

Pipelined ProtocolsPipelined ProtocolsPipelining: 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

04/19/2304/19/23 Wenbing ZhaoWenbing Zhao


Pipelining: Increased UtilizationPipelining: 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

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3!



Pipelining ProtocolsPipelining Protocols

Go-back-N: big picture: Sender can have up to N

unacked packets in pipeline Rcvr only sends

cumulative acks Doesn’t ack packet if there’s

a gap Sender has timer for oldest

unacked packet If timer expires, retransmit

all unacked packets

Selective Repeat: big pic Sender can have up to N

unacked packets in pipeline Rcvr acks individual

packets Sender maintains timer for

each unacked packet When timer expires,

retransmit only unack packet



Go-Back-NGo-Back-NSender: 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 pkt n and all higher seq # pkts in window



GBN: Sender Extended FSMGBN: Sender Extended FSM

Waitstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1)

timeout

rdt_send(data)

if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) // start timer if first unacked pkt start_timer nextseqnum++ }else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) // no more unacked pkts stop_timer else start_timer

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) && corrupt(rcvpkt)



GBN: Receiver Extended FSMGBN: Receiver Extended FSM

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! Re-ACK pkt with highest in-order seq #

Wait

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)



GBN inGBN inactionaction



Selective RepeatSelective 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



Selective Repeat: Sender, Receiver Selective Repeat: Sender, Receiver WindowsWindows



Selective RepeatSelective 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-1]:

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 ActionSelective Repeat In Action



Selective Repeat:Selective Repeat: Dilemma 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)

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



Non-Sequential Receive Non-Sequential Receive ProblemProblem The problem is caused by the overlap of sequence

number between the new receiving window and the old receiving window

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

0 1 2 3 4 5 6

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

Overlap Overlap



Non-Sequential Receive Non-Sequential Receive ProblemProblem Solution:

make sure no overlap when receiver advances its window Make window size w =1/2 range of seq numbers

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

0 1 2 3

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

No Overlap



UDP: User Datagram ProtocolUDP: User Datagram Protocol

“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?Why is There a UDP?

No connection establishment (which can add delay)

Simple: no connection state at sender and receiver

Small segment header No congestion control: UDP can blast away

as fast as desired



UDPUDP Often used for streaming

multimedia apps Loss tolerant Rate sensitive

Other UDP uses DNS SNMP

Reliable transfer over UDP: add reliability at application layer

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header



UDP ChecksumUDP 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?

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



TCP: OverviewTCP: Overview 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: OverviewTCP: Overview

TCP connection is byte stream, not message stream, no message boundaries

TCP may send immediately or buffer before sending Receiver stores the received bytes in a buffer


04/19/2304/19/23 EEC-484/584: Computer NetworksEEC-484/584: Computer Networks Wenbing ZhaoWenbing Zhao

TCP Segment StructureTCP Segment Structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pnterchecksum

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)

A TCP segment must fit into an IP datagram!


The TCP Segment HeaderThe TCP Segment Header Source port and destination port: identify local end points of the

connection Source and destination end points together identify the connection

Sequence number: identify the byte in the stream of data that the first byte of data in this segment represents

Acknowledgement number: the next sequence number that the sender of the ack expects to receive Ack # = Last received seq num + 1 Ack is cumulative: an ack of 5 means 0-4 bytes have been

received TCP header length – number of 32-bit words in header


The TCP Segment HeaderThe TCP Segment Header URG – indicates urgent pointer field is set Urgent pointer – points to the seq num of the last byte in a

sequence of urgent data ACK – acknowledgement number is valid SYN – used to establish a connection

Connection request: ACK = 0, SYN = 1 Connection confirm: ACK=1, SYN = 1

FIN – release a connection, sender has no more data RST – reset a connection that is confused PSH – sender asked to send data immediately


The TCP Segment HeaderThe TCP Segment Header Receiver window size –number of bytes that may be

sent beyond the byte acked Checksum – add the header, the data, and the conceptual

pseudoheader as 16-bit words, take 1’s complement of sum For more info: http://www.netfor2.com/tcpsum.htm

http://www.netfor2.com/checksum.html Options – provides a way to add extra facilities not

covered by the regular header E.g., communicate buffer sizes during set up


TCP Sequence Numbers and ACKsTCP Sequence Numbers and ACKs

Sequence numbers: 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’, echoes

back ‘C’

timesimple telnet/ssh scenario

Documents

EEC-484/584 Computer Networks