CIS679: UDP and Multimedia

1
CIS679 UDP and Multimedia

• Review of last lecture
• UDP and multimedia

2
Review of Last Lecture
TCP Window-based mechanism
/ slowstart is over / / Congwin gt
threshold / Until (loss event) every w
segments ACKed Congwin threshold
Congwin/2 Congwin 1 perform slowstart
3
UDP

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

4
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 app
• 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

5
UDP segment structure

• 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!

32 bits
source port
dest port
Length, in bytes of UDP segment, including header
checksum
length
Application data (message)
UDP segment format
6
Multiplexing/demultiplexing
delivering received segments to correct app
layer processes
gathering data from multiple app processes,
enveloping data with header
receiver
P3
P4
application-layer data
segment header
P1
P2
segment
H
t
M
segment
7
UDP Multimedia

• Put flow control, congestion control into
  application.
• Retransmit if packet deadline not past
• Move on if packet deadline is past
• Dont respond to Congestion
• Not a nice citizen.
• Possible to cause congestion collapse

8
UDP Consequences

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

9
Unfairness

• When UDP and TCP compete, UDP wins by pushing TCP
  into congestion

10
Multimedia Delivery

• Even when using UDP, applications should respond
  to congestion end-to-end.
• Need to promote nice behavior or TCP-friendly
  behavior.
• Emerging applications shouldnt kill the
  performance of nice applications.

11
TCP-Friendly

• Throughput of a TCP connection
• P the packet size
• p the lost probability of a packet
• Limit flows to TCP-style BW
• Dont know RTT exactly
• Why should everyone follow this exactly?
• Monitoring individual flows difficult

12
Rate-based Adaptation

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

13
Packet-pair
14
Packet-pair Technique

• Timestamp packets on receipt - t1, t2
• Inform sender d t2 - t1, bottleneck BW (d)/P,
  P size of first packet.

15
Issues of Packet-pair

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

16
Hop-by-Hop

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

17
Conclusion

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