Architecture and Pragmatics of Serverdirected Transcoding

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
Transcoding Proxy
3
Problem with transcoding proxies
Q50, 5831 bytes
JPEG, 200x267 Q34, 5815 bytes
JPEG, 600x800 Q3, 5830 bytes
JPEG, 600x800 Q50, 48617 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

Request
Request
Origin Server
Transcoding Proxy
Client
Response directives
Transcoded response
Fetch applet

• Size and reusability of applets?

7
HTTP protocol extensions

• 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

SDT-applet http//example.com/crop.jar SDT-parms
crop-origin140300, crop-size100,100
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 lt 100x100
• Client cannot display images gt 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
Client parameters
SDT-parms
Transcoded response
Transcoding applet
response
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 2
Control 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)
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