1. Streaming video over wireless link
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

2. Agenda Main issues with streaming over wireless link
Link layer approach
Transport protocol approach (to be added)
Conclusions and future work
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

3. Video over wireless link
Typical scenario: video transmission from set-top box to the (mutiple) screens
wireless
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

4. Video over wireless link (II)
Wireless link properties:
High losses
Low troughput
High jitter
Typical perceived quality issues:
Artefacts
“Hick-ups”
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

5. IP (Internet Protocol)
Techniques we look at
OSI stack:
application layer
MPEG en-/decoder
MPEG-packetizer
transport layer
TCP, UDP/RTP
network layer
IP (Internet Protocol)
packet scheduler
link layer
driver
physical layer
WLAN
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

6. Simplified sender/receiver communication
video source
video sink
sender buffer
receiver buffer
Explain how the buffers influence jitter and latency
Explain why it’s not usefull to use the sender buffer bigger than the receiver buffer
Explain that the size of the receiver buffer is oftern limited and that for sake of lower latency we may want smaller buffers
With smaller buffers more data will get lost
That’s why we need to consider sending first of all what is most important. If we need to drop data, then we drop pieces which influence our quality least
wireless interface (sender)
wireless inerface (receiver)
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

7. Link layer approach Sender Application/ encoder TCP/IP stack
MAC-level retries
video stream
driver/scheduler buffer
IP packets
TCP/IP stack
Explain here what the MAC retries means, how it influences the fullness of the scheduler buffer, how the jitter occurs.
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

8. I BBPBBPBB(I) MPEG encoding GOP (group-of-pictures):
Frame types: I, P, B
Typical GOP structure and dependances:
I BBPBBPBB(I)
So, losing B frames is less undesirable than P frames. Same with P and I accordingly.
Importance of a frame decreases in following order: I, P, B
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

9. Scheduling of frames (I)
Packetizing
Assign prioritites to packets according to frame types:
P(B) = 1
P(P) = 2
P(I) = 3
Scheduling
Packets with higher priorities should get a better chance to be sent
Involved layers
application layer
transport layer
network layer
driver
link layer
IP (Internet Protocol)
TCP, UDP/RTP
MPEG en-/decoder
packet scheduler
physical layer
WLAN
MPEG-packetizer
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

10. Scheduling of frames (II)
Scheduling algorithm (level of frames)
incoming frame
buffered frame
sent frame Fi Fb Fs
if P(Fi) >= P(Fb)
Fb := Fi
else
Fi := 0 (discard Fi)
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

11. Advantages of link layer approach
We only need to modify the sending part
it will work with any terminals supporting RTP reception
it is an alternative to layered scalable video
it is very reactive against fast network fluctuations
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

12. Transport layer approach
If...
we don’t have direct access to the wireless interface
we don’t want to modify it
we want more reliability, than UDP/RTP does
... then we would like to look at the tranport layer
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

13. TCP-RTM*: “semi-reliable” protocol
Combines retransmission abilities of TCP and non-blocking behavior of RTP
Retransmission mechanisms reused from TCP
Packets that cannot be delivered in timely fashion are being skipped
Application techniques resemble those for RTP (surveyed later)
Requires minimum of TCP-code modifications, can be implemented as another TCP-option
* Sam Liang, David Cheriton, “TCP-RTM: Using TCP for Real Time Applications,” Submitted to IEEE ICNP ’02, 2002
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

14. TCP-RTM receiver – “read-over-hole” technique
Receiving application
Too late to resend - acknowledge
step2
step3
segment consumed by application
segment received but not yet consumed by application
skipped segment
empty buffer ?
re-request
on dup-acks
step1
snd_cwnd !
So, this is the main idea of the TCP-RTM. The situation depict here is a “bad-luck” situation. Our interest is to have no losses visible to application at all. The receiving application should read as late as possible in order to let the protocol to resend eventually lost segments. It should be very clear at this point what and why we are doing.
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

15. TCP-RTM – application techniques
Receiver application doesn’t read from the buffer until the data is needed for timely playback
this provides fixed play-back delay
timestamps are needed for this
TCP-RTM supports application-level framing (ALF)
one application frame per TCP-segment – hence, always integral application frames are lost
every application write/read operation deals with 1 application level frame
ALF helps effective recovery from the losses
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

16. TCP-RTM and burst losses
empty buffer
Receiving application ?
step1
snd_cwnd
re-send on rto
step2
step3
out-of-date
segments consumed by application
received out-of-date segments
segments received but not yet consumed by application
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

17. Recovery price Burst loss size, packets
rto is doubled with every packet loss
Burst loss size, packets
Minimum latency to cover the losses, mS 1 70 2
260 3
220 4
700 5… -*
buf_size = 64K, frame_size=1K,
frames sent every period=20mS
Near-exponential dependency – congestion window doesn’t grow large enough to trigger the dup-ack retransmission
* - TCP-buffer gets full
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

18. TCP-FCW vs TCP-RTM
TCP-RTM wasn’t meant to be used on burst losses networks
Losses of more than one segment in a row are not expected to happen
To be used on the real Internet
Be TCP friendly (use congestion avoidance)
TCP-FCW meets different assumptions
To be used on the QoS enabled networks with bandwidth reservations
“Send as fast as you can, but not faster than requested by the application”
Thus, we can control the bit-rate of the transmission on the application level
Provide “immediate recovery” – no slow start
It’s not meant to be used on the current Internet
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

19. TCP-FCW: “free-congestion-window”
Receiving application ?
re-request –
on dup-acks again
step1
step2
step3 !
resent
packet consumed by application
packet received but not consumed by application
skipped packet
empty buffer
recovered packet
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

20. Evaluation
Result: exponential growth of latency in case of TCP-RTM vs linear growth in case of TCP-FCW
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

21. Further work Link-layer Protocol-layer creating math. model evaluation
combination TCP sender + TCP-RTM receiver
much higher bit-rates should become possible
the behavior of sliding window should be investigated
packetizing should be provided on the application level (i.e. by means of delimiters)
4-May-19
Sergei N. Kozlov,
TU/e Informatica, System Architecture and Networking

22. Questions? 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl
TU/e Informatica, System Architecture and Networking