streaming video over wireless link

Apr 19, 2023 Sergei N. Kozlov, [email protected]/e Informatica, System Architecture and Networking

1

Streaming video over wireless link


2

Agenda

• Main issues with streaming over wireless link• Link layer approach• Transport protocol approach (to be added)• Conclusions and future work


3

Video over wireless link

• Typical scenario: video transmission from set-top box to the (mutiple) screens

wireless


4

Video over wireless link (II)

• Wireless link properties:– High losses– Low troughput– High jitter

• Typical perceived quality issues:– Artefacts– “Hick-ups”


5

Techniques we look at

OSI stack:

application layer

transport layer

network layer

802.11 driverlink layer

IP (Internet Protocol)

TCP, UDP/RTP

MPEG en-/decoder

packet scheduler

physical layer 802.11 WLAN

MPEG-packetizer


6

Simplified sender/receiver communication

video source

sender buffer

wireless interface (sender) wireless

inerface (receiver)

receiver buffer

video sink


7

Link layer approach

driver/scheduler buffer

Sender

TCP/IP stack

Application/

encoder

video stream

IP packets

MAC-level retries


8

MPEG encoding

• GOP (group-of-pictures):– Frame types: I, P, B– Typical GOP structure and dependances:

I BBPBBPBB(I)

• Importance of a frame decreases in following order: I, P, B


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

application layer

transport layer

network layer

802.11 driverlink layer

IP (Internet Protocol)

TCP, UDP/RTP

MPEG en-/decoder

packet scheduler

physical layer 802.11 WLAN

MPEG-packetizer

Involved layers


10

Scheduling of frames (II)

• Scheduling algorithm (level of frames)

Fi Fb Fs

incoming frame buffered frame sent frame

if P(Fi) >= P(Fb)

Fb := Fi

else

Fi := 0 (discard Fi)


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


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


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


14

TCP-RTM receiver – “read-over-hole” technique

Receiving application

Too late to resend - acknowledge

step2

Receiving applicationstep3

segment consumed by application

segment received but not yet consumed by application

skipped segment

empty buffer


?

re-request on dup-acks

step1

snd_cwnd

!


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


16

TCP-RTM and burst losses

empty buffer


?step1

? ?

snd_cwnd


re-send on rto

step2?? ?

Receiving applicationstep3

out-of-date

segments consumed by application

received out-of-date segments

segments received but not yet consumed by application


17

Recovery price

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

* - TCP-buffer gets full

• rto is doubled with every packet loss

Near-exponential dependency – congestion window doesn’t grow large enough to trigger the dup-ack retransmission


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


19

TCP-FCW: “free-congestion-window”


?



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


20

Evaluation

• Result: exponential growth of latency in case of TCP-RTM vs linear growth in case of TCP-FCW


21

Further work

• Link-layer– creating math. model– evaluation

• Protocol-layer– 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)– creating math. model– evaluation


22

Questions?

streaming video over wireless link

Documents