Transcript Adaptive continuous-media applications through the use of

Dynamic Reconfiguration of IP Domain
Middleware Stacks to Support Multicast
Multimedia Distribution in a Heterogeneous
Environment
….Basically attempting to give the optimum
multimedia reception quality to unequally
yoked receivers on a Mobile IP network
using features implemented in the
industry standard RTP protocol designed
for streaming networked multimedia. The
result should be ideal for resource
constrained mobile devices.
Stop waffling…….Explain it to me in simple
terms before I call security….
Internet …. A gigantic leap for mankind ….
A small step for those under the age of 5
All machines are equal…but some are more
equal than others eg. Laptops, Sun Sparcs
Mbone, Multicast, layered encoding….My
God, what are you talking about? All we
want to do is broadcast a baywatch video
Existing framework for multimedia conferencing
on Internet (This won’t change, I’ll just enhance it)
Conferencing applications use the Real-time
Transport Protocol
Receivers express interest in receiving
traffic by tuning into a multicast address &
network forwards traffic only along links with
down-steam recipients
No knowledge of group membership or routing
is available at source or receivers
Back to fluffy clouds or is it a sheep
with seven legs?
Differently ‘shaped’
computers on the
internet… A sort of
ushering in the new
socialist computer
society...
28.8 k
33.6 k
14.4 k
1.5 M B
Internet
B ackbone
64 k
512 k
128 k
Layered Encoding....Not bad...but not good enough
E n h an cem en t la yer 1
1 . 5 M b /s
R1
E n h an cem en t la yer 2
1 . 5 M b /s
E n h an cem en t la yer 3
S
R ou ter
1 . 5 M b /s
5 1 2 kb /s
L in k ca p a city
R2
1 2 8 kb /s
R3
S
1
S en d er
R 1 , R 2 , R 3 : R ec eiver 1 , 2 , 3
Simply, three different
quality streams sent
over the network (each
one building on the
previous)
The Kerryman’s Solution….
replicated streams
Sender creates
various quality
streams and lets
receivers pick and
mix….. wasteful of
bandwidth…. Each
up-stream link
carrys all streams
R2
C ross-traffic
20K
(15K )
(20K )
100K
28K
S
R4
64 k
42K
8K
R1
R3
H Q V ideo (16k)
R outer
LQ V ideo (9k)
A udio (4k)
T ext (2k)
C ross traffic
S
1
R
Sen der
R eceiver
Let me see a conceptual diagram before I
throw up.….
Layer
A pplication
7
S tream ing A pplications
P resentation
6
Java M edia Fram ew ork 2.0 A P I
S ession
C ham eleon Fram ew ork
5
C o d ecs
R en d erers
E ffects
Transport
4
R TP /R TC P
N etw ork
3
IP / M obile IP
D atalink
2
M A C D rivers
P hysical
1
N etw ork Interface C ard
QoS
The framework is a pure Java implementation using the
Java Media Framework (JMF) to transport multimedia
Nope.. Still doesn’t make sense to me…I’ll
just sit here and nod intelligently
Ex pe r im e n t a l
M edia and S tack R epository
V ideo
M edia and S tack R epository
Ev a l u a t io n
V ideo
Po in t s
C h am eleo n M u ltim ed ia S en d er
A udio
V ideo
M u ltim ed ia S en d er
1
1+2
T ext
A udio
T ext
V ideo
A u d io
Sp e c ific
Sta c k
S tream C ontrol
& U pdates
V id e o
Sp e c ific
Sta c k
Te xt
Sp e c ific
Sta c k
V ideo
G roup
T ext
G roup
A udio
G roup
N ew
Q oS
m odules
O bject skeleton
O bject adaptor
T C P S o cket
3
V ideo
A udio
3. P roxies to offload
com putation for m obile
devices
C ham eleon
M iddlew are
S ystem
M onitor
M obility,
B andw idth,
D isplay,
Location
E vents
1,2. M edia S pecific S tacks
S tream
& D ynam ic R econfiguration
S ubscription
S tatistics & S tack
C om ponent
R equests
T ext
S ession
M anager
N ew
Q oS
m odules
O bject R equest B roker
4
4. Q oS negotiation
com ponents
F iltered
A udio
G roup
F iltered
V ideo
G roup
F iltered
T ext
G roup
V ideo, A udio and T ext
5
T C P S o cket
B & W F ram es
5. M ulticast groups for
heterogeneous C lients
M em o ry
A u d io
V id eo
A u d io
V id eo
T ext
M em o ry
M em o ry
T ext
T ex
t
W ireless LA N C lient
D esktop 10M B C lient
G S M P D A C lient
A u d io
V id eo
T ext
C lient S tub
M em o ry
W ireless LA N C lient
A u d io
V id eo
T ext
M iddlew are library
M em o ry
D esktop 10M B C lient
A u d io
V id eo
T ext
M em o ry
Chameleon Architecture Components
What happens when you don’t eat your
Weetabix
The failings of a research scientist
S tre a m M a n a g e m e n t
D is p la y
In te rfa c e
C a p tu re
A p p lic a tio n
T ra n s m is s io n
A p p lic a tio n
S to ra ge
F a c ility
M u lti-S tre a m
M a n a ge m e n t
S e rv e r In te rfa c e
M e d ia R e c o rd in g
S tre a m in g S e rv e r
M e d ia D a ta b a s e
M u lti-S tre a m G U I
M o n ito r In te rfa c e
C o m p re s s io n
S tre a m M o n ito rin g
F ile /D a ta T ra n s fe r
M o n ito r Q o S
S e c u rity
C a p tu re In te rfa c e
E n c o d in g M o d u le
Screen resolu tion
D ispla y
ca pa bilities…
T ota l M em ory
A va ila ble
M em ory ...
M em ory
M on itor
D a ta Q u e ry T o o l
D isplay M onitor
S ys t em
M oni t or
Location
M onitor
B andw idth M onitor
M a xim u m
ba ndw idth
A va ila ble ba ndw idth
Pa ck et loss… .
L oca tion
V elocity … .
how to overload a diagram & confuse an audience
Basically - let
these ‘transcoder’
thing-a-mi-jigs do
all the hard work.
Let them resend
the missing pieces
- let them act as
big brother.
R e c e iv e r
M a x B a n d w id th
T ra n s c o d e r
M e d B a n d w id th
R o u te r
R e m o te S ite A
L a p to p M a c h in e X
M in B a n d w id th
T ran sco d er
M a c h in e Y
U n iv e rs ity o f U ls te r, M a g e e
V id eo S erver
M a c h in e Z
R o u te r x .xx .x x
M a c h in e Y
M a c h in e X
M a c h in e Z
T ran sco d er
M a c h in e X
•Saves Bandwidth
•Faster recovery
•Optimum quality
R o u te r x .xx .x x
M a c h in e Y
C o ng estio n
R eg io n
R o u te r x .xx .x x
M a c h in e Y
M a c h in e Z
R e m o te S ite B
1 – Media Specific Stack Configuration
Problem. Protocols stacks have traditionally been
monolithic chunks of code where all data regardless of
whether it is a continuous stream of bits with strict time
dependencies between those bits, or the packets
comprising an asynchronous message are sent through
the same stack.
The nature of the data is not considered however and
therefore there is no room for optimisation of the code
to create a more efficient service. In addition protocol
functionality can exist which is never invoked.
M edia and Stack Repository
Video
Chameleon M ultimedia Sender
Audio
Audio
Specific
Stack
Video
Video
Specific
Stack
Text
Text
Specific
Stack
Solution. We propose a propose a paradigm whereby media are transported
through an optimised stack constructed solely for that media/medium allowing
improved multimedia Quality of Services to be achieved even at run-time as
illustrated above. In our approach, for making applications adaptive, the
applications are composed from micro stack objects and the composition is
reconfigured when the operational environment is changed. Each stack object
has a function such as filtering and caching and a protocol profile manager can
dynamically reconfigure the object compositions for increased performance.
2 – Dynamic Runtime Stack Configuration
Problem.
Mobile devices will be
connected to a diverse range of network
types offering vastly differing levels of
bandwidth throughput.
In addition, fluctuations in throughput
and delay may also be experienced due to
congestion even while connected to a
particular network, (e.g. as witnessed in
the Internet) therefore it is important
that systems have the means to adapt to
the offered network QoS.
Solution. Dynamic protocol stacks can be invoked
which provide a ‘best-fit’ for each and every situation.
For example, in the case of a mobile device moving from a LAN into a cellular network
where the available bandwidth and the error rate change significantly, the middleware
could adopt bandwidth-conserving mechanisms, such as compressing the requests, (i.e.
trading off CPU for bandwidth in order to adapt itself to environmental changes) through
dynamic protocol stacks.
3 – Computation Offload for Constrained Devices
Problem. Current PDA/wireless devices have
limited processing power in comparison to their
desktop counterparts. This seems likely to be the
trend for the near future. Multimedia however has
strict real-time requirements with regards
reception; processing and display of media
therefore large reservoirs of multimedia are likely
to be inaccessible to these devices for the
foreseeable future. The need also exists for
facilitating mobile mobile users in handling
intermittent connectivity, location tracking, link
QOS constraint & session migration among others.
C ham eleon
M iddlew are
S ystem
M onitor
N ew
Q oS
m odules
M obility,
B andw idth,
D isplay,
Location
E vents
F iltered
A udio
G roup
S ession
M anager
N ew
Q oS
m odules
F iltered
V ideo
G roup
F iltered
T ext
G roup
B & W F ram es
M em o ry
A u d io
V id eo
A u d io
M em o ry
M em o ry
T ext
V id eo
T ext
W ireless LA N C lient
T ex
t
D esktop 10M B
G S M P D A C lient
C lient
Solution. Proxies located at the home agent/base station of each mobile client can
offload processing for memory-constrained devices. The proxy becomes responsible for
activities such as message queuing and forwarding, compression, access to streaming
sessions,
message
encryption
and
protocol
translation
among
others.
..for smallest possible client footprint, the proxy relieves the client library of most of the
work of maintaining state information about active sessions, filters and general system
monitoring facilities….may also perform another function as a cache for recent clips
4 – Quality of Service Middleware Components
Problem. TCP/IP networks are essentially besteffort conduits in which packets are sent wholesale,
without waiting in line for each other. Packets
routinely collide and hit congestion, causing tiny
delays and often requiring resends. Those delays,
usually measured in milliseconds, are meaningless with
data traffic but wreak havoc with time sensitive
multimedia traffic.
S y s tem
M onitor
M obility ,
B andw idth,
D is play ,
Loc ation
E v ents
C ham eleon
M iddlew are
N ew
Q oS
m odules
S es s ion
M anage r
N ew
Q oS
m odules
There is no clear picture of what it will take for better QoS to be deployed in enterprise
networks, and demand is not forcing fast solutions however solutions to many QoS
problems can be solved using application level QoS mechanisms and to date much of the
enterprise middleware available ignores or implements poorly priority assignments to media.
Solution. A set of negotiation protocols allowing real-time negotiation on QoS through
the application of dynamic transformation of media. Protocol profilers maintain a list of
adaptation thresholds and decisions to transcode data are taken in accordance in
accordance with media profiles mapped to bandwidth and end-host resource
characteristics. In addition, a Priority Queuing technique can give specific media streams
higher priority than less critical traffic so that during congestion periods, media streams
are queued as high, normal, medium, or low. Therefore, using Priority Queuing, all highpriority traffic is serviced first, then normal etc. This allows additional resource
reservation protocols and selected pricing schemes to be ‘slotted in’ at a later date.
5 – Heterogenity of Client Population
Problem. There are many types of network connected
mobile devices today with capabilities ranging from
powerful full specification laptop PC’s, to lower
powered PDA’s. Some devices will be capable of
displaying full colour 1600x1200 while others may only
manage black and white 100x60 screen resolution.
Networked devices range from broadband others to
GSM type service. Approaches to the problem have
involved sending the lowest common denominator
stream to all receivers, however this penalises the
more powerful mobile clients that receive far below
their true capabilities.
Server
M PEG /Audio-1
Layer 3, 44 kH z, 16
bit, stereo 128 kbps
Transcoder
M PEG /Audio-1
Layer 3 44kH z, 16
bit, m ono 64 kbps
D VI 8 kH z, 4 bit,
m ono, 32 kbps
M obile D evice
M obile D evice
Laptop, netw ork 128 kbps
PD A, netw ork 28 kbps
Solution. Providing various qualities of media through separate multicast groups can cater
for a heterogeneous mobile client population. Here a client can ‘pick and choose’ a Quality
of Service (QoS) in accordance with its capabilities. This mechanism offers movement
between multicast groups and transcoding of media within groups (no need to join a
separate group). A Secondary transcoding mechanism can complement the above coarser
grained technique by assuming responsibility for responding to quality fluctuations within
each group. Both techniques can be optimised to work with priorities being assigned to
differing streams within a link in order to allow different streams to be rate controlled
according to application-implied importance.
Server, Proxy and Client GUIs
Proxy GUI for snooping
and manipulating streams
Simple Client Player
Server GUI for streaming multiple QoS streams
to Multiple Mulitcast Group Locations
Experimental Verification of
(1) Media Specific Stack Configuration
Chameleon allows the insertion of a retransmission policy object such as ACK or NAK to
ensure reliability of data should the need arise. Using the NAK scheme, the sender tags a
message with a sequence number and the receiver only requests retransmission if there is
a gap between the expected and actually received message sequence number. However, in
the ACK scheme the sender tags a message with a sequence number and the receiver
acknowledges every message by sending an ACK back to the sender.
When no ACK has been received for a certain time, the sender retransmits the message.
In general, the NAK scheme uses very few extra messages if transmission failures are
rare, but latency can be very high if the transmission rate is low or if the failure rate is
high. This is due in part to the buffering of larger groups of data and the repercussions
upon other data should packets go astray.
Experiment Goal: To demonstrate that adapting the epoch message size of the NAK
protocol in relation to network losses can lead to an optimal protocol. The first part of
the experiment compares the performance of varying epoch sizes over a lossy network.
The second part utilises the secondary quality transformation technique, which
reconfigures the epoch policy to achieve an optimal throughout over a lossy network.
Experimental Verification of
(1) Media Specific Stack Configuration
10
9
Throughput (MBps)
Here we achieve an optimal stack through
dynamic reconfiguration. Examination of
the raw data however reveals that there is
18% lower throughput than the theoretical
maximum. We believe this is due to the
actual overhead involved in the system
reconfiguration. We have also to some
degree weighted the experiment to suit
our system as we have performed runs of
sufficient length in time to allow
adaptation to be detected and to benefit
the system, once reconfigured.
8
7
6
5
4
0
5
10
15
20
25
20
35
40
P a cke t L o ss ( % )
e p o c h s iz e 1 0 0
e p o c h s iz e 6 0 0
e p o c h s iz e 3 0 0
e p o c h s iz e 9 0 0
10
We believe the other cause of poorer
performance is simply the self-imposed
delay on the system when responding to
brief fluctuations in quality.
This is necessary to prevent incorrect
responses to random spikes in throughput.
Throughput (MBps)
9
8
7
6
5
4
0
5
10
15
20
25
20
P a cke t L o ss ( % )
e p o c h s iz e 1 0 0
35
40
Future Work or (Dream Work)
* By registering a domain name the package names used in the framework will
be assigned a unique name that conforms to the naming conventions that Sun
Microsystems have specified. This is important, as a unique name space for the
framework will be essential to prevent it from conflicting with other packages.
Therefore this should help to ease acceptance of the framework by
developers and to ensure that the framework is industry standard; exception
handling will have to be incorporated for every eventuality.
* Adoption of XML to allow system administrators to customise the multicast
groups will allow the system to be flexible enough for non-programmers to
alter its behaviour without the need for recompiling the system. It would also
be useful to implement a group selector that uses XML configuration for each
multicast group processor, which contains details about the bandwidth
limitations the processor is designed to support. Therefore a Group Selector
could be created to use this information when assigning clients to Multicast
groups. Group processors could also be distributed to relieve the bandwidth
requirement on any particular broadcaster.
Goodness, will this guy ever shut up?
* A layer broker similar to the over the air (OTA) mechanism that J2me uses
to download application to a mobile phone could also be developed. This
functionality will allow layers to be dynamically downloaded by a client as
needed. Security should be tightened (e.g. a form of encryption can be
introduced into the group processors). Another is that clients could be
validated by their IP address, thus only authorized clients would be able to
subscribe to a group processor.
* The files could be encoded using the Sorensen encoder. Files are currently
encoded using the CINEPAK codec. Compared with Cinepak, Sorenson Video
generally achieves higher image quality at a fraction of the data rate allowing
for higher quality, and faster downloading. It is designed for high quality at
data rates less than 200 kBps. This codec is capable of better picture quality
and smaller files than Cinepak. It requires more compression time than Cinepak
however but it supports temporal scalability, which lets a movie exported for a
high-end computer play back smoothly on a low-end computer.