Post on 25-May-2015
04/12/23 1
Architecture and Pragmatics of Server-directed Transcoding
Björn Knutsson and Honghui Lu, U. Penn
Jeffrey Mogul, HP WRL
2
Transcoding proxies
Problems that transcoding proxies solve Complex server content Highly variable network bandwidths Highly variable client capabilities: screen size, color
depth, encoding
Origin Server
TranscodingProxy
3
Problem with transcoding proxies
JPEG, 600x800 Q=50, 48617 bytes
JPEG, 200x267 Q=34, 5815 bytes
JPEG, 600x800 Q=3, 5830 bytes
Q=50, 5831 bytes
4
Server-directed transcoding (SDT)
Autonomous transcoding Proxy employs heuristics Risks loosing the meaning of the content Risks loosing opportunities for aggressive transcoding
Server-directed transcoding [Mogul WCW ’00] Server explicitly tells the proxy what to do Respects the end-to-end argument
5
Contributions
A specific protocol design
An applet architecture
A proxy architecture
Interesting transcoding applets
Experimental results
6
Basic architecture
Server-directives as mobile code – applets
Reference to applets attached to the HTTP response
Origin Server Transcoding
ProxyClient
Request
Transcoded response
Request
Response +
directives
Fetch applet
Size and reusability of applets?
7
HTTP protocol extensions
SDT-applet: http://example.com/crop.jarSDT-parms: crop-origin=140;300, crop-size=100,100
New HTTP response headers
No restrictions on the syntax of SDT-parms SDT-parms are interpreted by applets, not by proxies
Mechanism for reusing applets
8
Basic image transformations
Cropping
Scaling
Lossy compression
Color-depth reduction
De-animation
Format conversion
New basic transformations may be introduced …
9
Complex image transformations
An image must be adapted for many clients
Small screen Cropping, scaling
Low bandwidth Cropping, color-depth reduction, scaling Lossy compression, de-animation
Small screen and low bandwidth?
10
What should an applet look like?
Big, all inclusive applet Control complexity
Small, per image applet Reusability
Category-specific applet One applet that applies to a set of images
11
Example applet: 'crop-interp'
For images with one important subject and surroundings that just add flavour
First interpolate between a set of crop boxes
Shrinks the inner most cropped image if necessary
12
Other category-specific applets
Landscape panorama Apply lossy compression first Then crop …
Banner ad Reduce color depth first De-animation, scaling …
13
Who is in control?
Seems the server controls everything, via the applet
But, what if Server – image cannot be scaled to < 100x100 Client – cannot display images > 50x50 Proxy – does not have enough CPU cycles for this!
Who decides what transformations to apply?
14
Who is in control of what?
Origin server controls the semantics
Client controls the presentation
Proxy controls the resource used for transcoding, and network traffic
Server controls are delegated to its applet running at proxy
15
Rules for resolving conflicts
Any party has a veto Server or proxy can decide not to transcode an image The client can decide to reject an image
Server is free to compromise semantics in order to meet client and proxy preferences, if the server is willing
16
Proxy environment
Transcodingapplet
response
Transcodedresponse
SDT-parms
Client parameters
Proxy parameters
17
Revisit ‘crop-interp’
For images with a main subject
Simple control
Crop-interp(input image, output image, SDT_params, /* crop boxes */ client parameters, proxy parameters)
18
The pragmatics of an applet
Applet size is still large Image I/O Bit manipulations for basic transformations
Performance is bad Compute intensive Interpreted code is slow
19
The pragmatics of an applet
Separate common, basic functions from the control
Function applet
Control applet 2Control applet 1
Implement basic functions with native code
20
Prototype proxy implementation
Basic, un-optimized implementation No caching of either image or transcoding applet Sequential store and forward Implemented in Perl
Supports Perl applets
Pre-installs native functions (ImageMagick)
Long-term : augment Squid to support Java applets
21
Experimental environment
Penn CIS Web server
Proxy: IBM ThinkPad, 1.2GHz Pentium III, 384MB RAM
10 Mbps Ethernet between server and proxy
Simulate various proxy-to-client bandwidths using Linux Traffic Shaper
22
Transcoding overhead
“crop-interp”: 2KB Perl code
Original image: 600x800, 65982 bytes
Target size: 200x267, 5831 bytes
Download applet 30ms
Execute applet 86ms
23
Effect on end-to-end latency (ms)
56 Kbps 768 Kbps
No proxy
600x8009680 510
Proxy transcoding
200x2761120 211
24
Summary of contributions
A specific protocol design
An applet architecture
A proxy architecture
Interesting transcoding applets
Experimental results Improves end-to-end latency even on 768 Kbps links
25
Future work
Applet design Size, reusability, performance
Proxy execution environment Native functions API
Security issues Resource consumption of transcoding applets
Caching issues cache replacement policy Matching client requests with the cached items
Transform contents other than images Extend to support CDNs and streaming media
26
Related work
Proxy transcoding Brooks et al. 1995, Fox et al. 1996 Chandra and Ellis 1998
Introducing code into proxy Active Cache, Cao et al. 1998 Active Names, Vahdat et al. 1999
Other related ideas Active networking IBM WebSphere ICAP