EEC-484/584 Computer Networks Lecture 7 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer Networking book)

10/3/2015 EEC-484/584: Computer Networks Outline Reminder  No class next Monday (Columbus Day) Reliable data transfer Pipelining protocols UDP Wenbing Zhao

rdt3.0: channels with errors and loss New 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 Wenbing Zhao 10/3/2015 EEC-484/584: Computer Networks

rdt3.0 sender 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) ) Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) 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)    Wenbing Zhao 10/3/2015 EEC-484/584: Computer Networks

rdt3.0 in action Wenbing Zhao 10/3/2015 EEC-484/584: Computer Networks

rdt3.0 in action Wenbing Zhao 10/3/2015 EEC-484/584: Computer Networks

Performance of rdt3.0 rdt3.0 works, but performance stinks ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: m U sender : utilization – fraction of time sender busy sending m 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link m network protocol limits use of physical resources! Wenbing Zhao 10/3/2015 EEC-484/584: Computer Networks

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 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks Pipelining: Increased Utilization first packet bit transmitted, t = 0 senderreceiver RTT last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Increase utilization by a factor of 3! 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks Pipelining 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 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks Go-Back-N Sender: k-bit seq # in pkt header “window” of up to N consecutive unack’ed pkts allowed r ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” m may receive duplicate ACKs (see receiver) r timer for oldest in-flight pkt r timeout(n): retransmit pkt n and all higher seq # pkts in window 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks GBN: Sender Extended FSM Wait start_timer udt_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)+1 If (base == nextseqnum) // no more unacked pkts stop_timer else start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt)  10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks GBN: 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=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum)  10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks GBN in action 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks 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 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks Selective Repeat: Sender, Receiver Windows 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks Selective 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 # Sender pkt n in [rcvbase, rcvbase+N-1] r send ACK(n) r out-of-order: buffer r in-order: deliver (also deliver buffered, in-order pkts), advance window to next not- yet-received pkt pkt n in [rcvbase-N,rcvbase-1] r ACK(n) otherwise: r ignore Receiver10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks Selective Repeat In Action 10/3/2015 Wenbing Zhao

EEC-484/584: Computer Networks 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) Q: what relationship between seq # size and window size? 10/3/2015 Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks Non-Sequential Receive Problem The problem is caused by the overlap of sequence number between the new receiving window and the old receiving window Overlap Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks Non-Sequential Receive Problem Solution:  make sure no overlap when receiver advances its window  Make window size w =1/2 range of seq numbers No Overlap Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks UDP: 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 Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks 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 Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks UDP 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 Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks 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. But maybe errors nonetheless? Goal: detect “errors” (e.g., flipped bits) in transmitted segment Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks TCP: 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 Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks TCP: 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 Wenbing Zhao

10/3/2015 EEC-484/584: Computer Networks Wenbing Zhao TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used 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 willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP) A TCP segment must fit into an IP datagram!

10/3/2015 EEC-484/584: Computer Networks Wenbing Zhao The 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

10/3/2015 EEC-484/584: Computer Networks Wenbing Zhao The 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

10/3/2015 EEC-484/584: Computer Networks Wenbing Zhao The 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: Options – provides a way to add extra facilities not covered by the regular header  E.g., communicate buffer sizes during set up

10/3/2015 EEC-484/584: Computer Networks Wenbing Zhao TCP 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 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet/ssh scenario