CSE679: Computer Network Review r Review of the uncounted quiz r Computer network review

Network Layers

Transport Layers r TCP/UDP

TCP r Transport Control Protocol r Flow control and Responds to congestion r Reliable In-order delivery r “Nice” Protocol

TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data 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)

Reliable Delivery r Sender, Receiver keep track of bytes sent and bytes received. r Acks have an indication of next byte expected. r Three duplicate acks considered a packet loss - sender retransmits

TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say, - up to implementer 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 scenario

TCP Flow Control r Window based r Sender cannot send more data than a window without acknowledgements. r Window is a minimum of receiver’s buffer and ‘congestion window’. r After a window of data is transmitted, in steady state, acks control sending rate.

Flow Control

TCP Slowstart r exponential increase (per RTT) in window size (not so slow!) r loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) Slowstart algorithm Host A one segment RTT Host B time two segments four segments

TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart Congestion avoidance 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs

UDP r No reliability, flow control, congestion control. r Sends data in a burst. r Provides multiplexing and demultiplexing of sources. r Most multimedia applications using UDP

UDP: User Datagram Protocol [RFC 768] r “no frills,” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired

UDP segment structure r often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses (why?): m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recover! source port # dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header

UDP Consequences r Most applications today use TCP r Stability of network relies on congestion response of applications r Large scale use of UDP could lead to problems - no congestion response r Large number of multimedia applications expected - move larger amounts of data

Unfairness r When UDP and TCP compete, UDP wins by pushing TCP into congestion

TCP-Friendly r Throughput of a TCP connection m P: the packet size m p: the lost probability of a packet r Limit flows to TCP-style BW r Don’t know RTT exactly r Why should everyone follow this exactly? r Monitoring individual flows difficult

Conclusion r TCP m TCP not well suited to multimedia. m TCP is a well understood, ‘nice’ protocol. m Multiplicative decrease/additive increase allows fair sharing of BW and avoids congestion collapse. m UDP is being used by multimedia developers. r UDP m UDP can be tuned to better support multimedia applications. m TCP-friendly m Rate-based adaptation Packet-pair m Hop-by-hop control