CIS679: UDP and Multimedia r Review of last lecture r UDP and multimedia

Review of Last Lecture /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart TCP Window-based mechanism

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

application transport network M P2 application transport network Multiplexing/demultiplexing receiver H t H n delivering received segments to correct app layer processes segment M application transport network P1 MMM P3 P4 segment header application-layer data gathering data from multiple app processes, enveloping data with header Multiplexing: Demultiplexing:

UDP & Multimedia r Put flow control, congestion control into application. r Retransmit if packet deadline not past r Move on if packet deadline is past r Don’t respond to Congestion r Not a “nice” citizen. r Possible to cause congestion collapse

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

Multimedia Delivery r Even when using UDP, applications should respond to congestion end-to-end. r Need to promote “nice” behavior or “TCP-friendly” behavior. r Emerging applications shouldn’t kill the performance of “nice” applications.

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

Rate-based Adaptation r Have a notion of allowed rate -adjust rate to avoid congestion - reduce rate before packet loss. r Packet-pair: Send a pair of packets, watch the time separation of acks r The delay between acks gives an indication of bottleneck BW

Packet-pair

Packet-pair Technique r Timestamp packets on receipt - t1, t2 r Inform sender d = t2 - t1, bottleneck BW = (d)/P, P = size of first packet.

Issues of Packet-pair r With parallel transfers, both packets may arrive simultaneously at the receiver -inflating available BW r Ack compression leads to incorrect BW estimation. r Can it be improved by sending more packets? r Possible to decouple rate adaptation and reliable delivery

Hop-by-Hop r Possible to do flow control hop-by-hop r Send backward pressure to reduce rate when queues are building up r Tough to control individual flows r Every network element need to implement -not just endpoints.

Conclusion r UDP can be tuned to better support multimedia applications. r TCP-friendly r Rate-based adaptation m Packet-pair r Hop-by-hop control