THINC: An Architecture for Thin-Client Computing Ricardo A. Baratto [[e-mail]]

1
THINC An Architecture for Thin-Client
ComputingRicardo A. Baratto ricardo_at_cs.columb
ia.edu
2
(No Transcript)
3
problems
4
1. management
5
PCs in use worldwide (2004)
6
2. operating cost
moveaddchange1000 per incident
7
3. availability
8
4. security
9
5. work area
10
Thin-Clients
11
(No Transcript)
12
(No Transcript)
13
Benefits

• simplify IT management
• minimize cost of desktop failures
• transparent user mobility
• continuous computing access
• secure computing services
• improve user/computer work areas
• utilize resources efficiently

14
why now?
15
1. network capacity
16
(No Transcript)
17
(No Transcript)
18
2. network connectivity
19
(No Transcript)
20
Related Work
21
(No Transcript)
22
Display Pipeline
applications
windowsystem
displaydriver
framebuffer
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
applications
windowsystem
displaydriver
framebuffer
27

• Blind encoding
• Client pull slow update rate

28
(No Transcript)
29
(No Transcript)
30
Proposal THINC a thin-client architecture to
replace PCs
31
Goals

• minimize latency
• simple and portable
• transparent operation

32
1. Remote Display
33
Proposed Architecture
34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
Display Protocol

• 2D Primitives
• Copy, Solid and Tile Fill, Bitmap, Raw
• Video
• 3D Primitives

39
two key problems
how do we translate from application commands
to the display protocol?
how and when do we send display updates?
40
(No Transcript)
41
translation
42
basic static translation
DrawAPI
standarddevicedrivercommands
THINCcommands
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
video first-class citizen
47
(No Transcript)
48
YUV

• Standard hardware interface
• Format independence
• Hardware acceleration (fullscreen for free!)

49
3D

• UI moving towards 3D backends
• Quartz, Avalon, Xgl
• Animations, transparency, ...
• Games the next frontier?

50
delivery
51
(No Transcript)
52

• push, don't pull
• don't block sending updates

53
(No Transcript)
54
(No Transcript)
55
2. Remote Session
56
(No Transcript)
57
(No Transcript)
58
(No Transcript)
59
usb/ip modifications

• need a transport protocol
• performance and resilience

60
(No Transcript)
61
benefits

• simplification
• abstract generic functionality
• resource management
• open issue
• performance impact?

62
(No Transcript)
63
resource management

• Priority Interactive response
• Classes of service
• Requested by components

64
(No Transcript)
65
synchronization

• time as first-class characteristic
• intra and inter stream
• stored media and real-time content

66
3. Backend
67
MobiDesk
68
A Virtual Hosting Infrastructure

• ZAP OS virtualization Osman et al
• MOVE network virtualization Su
• THINC remote access

69
4. Security
70
(No Transcript)
71
A2M

• Protection Indirection-based overlay
• Exploit traffic asymmetry Only protect uplink

72
(No Transcript)
73
Secure Remote Display Access

• Video card as the only trusted component
• Decryption in the GPU
• Issues
• Encoding, compression?
• Other components?

74
Preliminary Experimental Results
75
(No Transcript)
76
Configurations
LAN Desktop WAN Desktop 802.11g PDA
77
Web Browsing Performance Interactive Latency
78
LAN Desktop Web Browsing Performance
79
WAN Desktop Web Browsing Performance
80
802.11g PDA Web Browsing Performance
81
Audio/Video Performance Playback Quality
82
LAN Desktop A/V Performance
83
WAN Desktop A/V Performance
84
802.11g PDA A/V Performance
85
Status

• Remote display SOSP 2005
• Audio
• Audio/Video Synchronization Kim
• MobiDesk MobiCom 2004
• A2M Stavrou,Keromytis and Secure Remote Display
  Cook, Keromytis

86
ToDo

• 3D
• USB
• Session and resource management
• All-media synchronization

87
Schedule

• USB Summer 2005
• Session, resource management Summer/Fall 2005
• All-media synchronization Fall 2005
• 3D Fall 2005/Spring 2006