Supporting Heterogeneous Packet Flows in the Internet

uptightexampleΔίκτυα και Επικοινωνίες

24 Οκτ 2013 (πριν από 4 χρόνια και 19 μέρες)

58 εμφανίσεις

1

Supporting Heterogeneous Packet Flows in
the Internet

Jia Ru Li, Sungwon Ha, Vaduvur Bharghavan


TIMELY Research Group

http://timely.crhc.uiuc.edu

University of Illinois at Urbana
-
Champaign

{juru,s
-
ha,bharghav}@timely.crhc.uiuc.edu

http://timely.crhc.uiuc.edu


2

Heterogeneous Packet Flows

In a heterogeneous packet flow, different packets of the same

flow can have different QoS requirements


Multimedia flows are “heterogeneous” in nature


e.g. MPEG (control, I, P, and B frames), VR (control, text, audio, video), etc.


Applications may have “frame
-
specific” QoS policies for




reliability, priority, deadlines, dependencies



Goal is to maximize the
“goodput”

for the application while adapting to
the dynamics of the network


Application specifies the QoS policies; transport layer provides the
mechanisms to implement these policies





What are the trade
-
offs in moving the mechanisms for
implementing QoS policies in heterogeneous packet flows


from the application to the transport?

3

Current Transport Protocols


TCP and UDP are at two extremes


RTP provides realtime transport, but not the per
-
frame policies we want


Currently, multimedia applications handle heterogeneity as follows:

UDP

TCP

Unreliable

Reliable



Sequenced



Stream delivery



Delay unbounded



Unsequenced



Unreactive



Application level mechanisms





split a heterogeneous packet flow into component packet flows


(e.g. layers)



possibly open a distinct connection for each component packet flow



explicitly provide mechanisms for implementing QoS requirements in

the application

4

HPF: A Transport Protocol for Supporting
Heterogeneous Packet Flows


Supports
framing
.


Frame
-
specific QoS policies for reliability, priority, deadline,
dependencies


Guarantees sequencing,
selective reliability
.


Provides
“goodput control”
.


How much to send (estimates the dimensions of the the connection
pipe)


What to send (determines how best to fill up the pipe)


Propagates application
-
specified priorities as hints to network
routers.


Helps network routers preferentially drop low
-
priority packets.

5

HPF Architecture

Read/Write frames or packets

Specify priority, reliability, deadline, dependency

Optional:

congestion feedback,


priority
-
based packet drop,


rate feedback, delay bounded delivery

Network Layer

RC sub
-
layer

GC sub
-
layer

AF sub
-
layer

Application

Frame
-
> packet

Rate, RTT

Send/Receive frames

Send/Receive packets

HPF

API

Segmentation / Reassembly

Conversion frame policies into packet policies

Sequencing

Reliability and timing

Windowing

Flow control

Rate control

Estimation of running average of rate

Estimation of round trip time

6

Selective Reliability and Sequencing

Reliable (R):





Unreliable deadline bound (D):





Unreliable best effort (B):

retransmitted till successfully

acknowledged by receiver

transmitted at most once

treated like reliable packet

till deadline violation is

predicted, then treated like

unreliable best effort packet

7

Selective Reliability and Sequencing

One of the more tricky questions is:


how do we move the receiver’s window forward?

snd_una

snd_nxt

rcv_nxt

sender

receiver

Packet Header

R only:

if (
rcv_nxt

==
s
) and (receive
s
)

rcv_nxt

=
s

+ 1

s:
sequence number

R/B only:

if (
rcv_nxt >= h+1
) and (receive
s
)

rcv_nxt

= max{
rcv_nxt, s + 1
}

h:
previous reliable


sequence number

R/B/D:

if (
rcv_nxt >= h + 1
) and (receive
s
)

rcv_nxt

= max{
rcv_nxt
, max{
w
}}

w:
lower bound

on window advance


8

Selective Reliability and Sequencing

Rcv_nxt <=11

R:reliable packet


s:sequence number

D:unreliable delay
-
bounded packet

h:previous reliable pkt sequence number

B:unreliable best effort packet

w:move the receiver window up to at least w, if this pkt is received

Cack: cumulative ACK


Receiver window: between read_nxt & rcv_nxt

Snd_una=11

Cack=12

Cack=12

Rcv_nxt=12

Rcv_nxt=12

Pkt2
D

s=12

h=11

w=12

Pkt4
B

s=14

h=11

w=12

Pkt1
R

s=11

h=10

w=12

Pkt1
R

s=11

h=10

w=12

Pkt3
B

s=13

h=11

w=12

Pkt3
B

s=13

h=11

w=12

Pkt2 is predicted

to violate delay bound.

Is deleted

Cack=16

Rcv_nxt=16

Pkt6
R

s=16

h=11

w=17

Pkt5
B

s=15

h=11

w=16

Snd_nxt=18

Pkt7
B

s=17

h=16

w=18

9

Goodput control

sender

receiver

r
app
(t)

r
inst
(t)

r
savg
(t)

r
lavg
(t)

transport

rate adaptation

r
inst
(t)

r

t


application

rate adaptation

r
inst
(t)

r

t

r
app
(t)

Priority/Deadline/Dependency

dropping

network

10

Framing

Sender

Receiver

a

frame
-
specific QoS policy

b

a

a

a

a

b

b

b

a

a

a

a

b

b

b

Frame mode :

b

a

a

b

b

b

blank

Read 1

Read 3

Read 2

Stream mode:

11

Some Implementation Issues


Use socket API with some enhancements:


socket()


setsockopt(HPF_ENABLE)


listen(), connect()


sendmsg(policies)


readmsg(), getsockopt(REPORT_LOSS)


getsockopt(rate)


Very easy to program: ported TCP
-
based network video
player by changing under 20 lines of code (at obvious
places)


Defaults to TCP if either end host is HPF unaware


Multicast extensions to HPF are ongoing

12

Evaluation Platforms


NS simulation

(source available)


VCR from Oregon Graduate Institute (network video player)


User level implementation (Linux, Solaris, NT)


Linux Kernel

(source available)


NT kernel version is ongoing



Currently used in DARPA ITO Quorum Reference
Implementation as the transport protocol by Teknowledge
Corp. and Open Group

13

Performance


2MB file transfer, HPF/TCP speedup : 0.99971


LAN test


High priority packets ratio : 50%
-

5%


Time improvement vs TCP : 10%
-

42%


Loss




: 5%
-

24%


WAN test over Internet



High priority packets ratio : 66%
-

5%,


Time improvement vs TCP : 32%
-

70%


Loss




: 0.7%
-

7.86%


All pkts are unreliable (UDP like) : Improvement: 75%, loss 7.86%


MPEG
-
1 with congestion


Priority drop

loss percentage: I =0%

P=0%

B=24%


No Priority drop

loss percentage: I=20%

P=20%

B=8%


Comparisons with RTP ongoing work

14

Unresolved Issues/Ongoing Work


Optimizing the protocol overhead


Analytical evaluation of the goodput control
mechanisms


Quantitative comparison with other recent
approaches


Multicast extensions


Non
-
trivial wide area deployment and tests

15

General Information


Source available for linux 2.0.(31
-

36) and ns2


HPF paper in Infocom 1999 (extended version in
preparation)


Website: http://timely.crhc.uiuc.edu/HPF


Email contact: bharghav@crhc.uiuc.edu