Automatic encoding selection: was: (Re: Compression questoin)

[W. Brian Blevins]

Dub,

> Re: Compression questoin
> 
> From: Dub Dublin (dub "at" infowave.com)
> Date: Mon Oct 30 2000 - 19:18:59 EST 
> 
> 
> Constantin, Brian, and especially Wez: 
> 
> In the upcoming revisions to VNC to support more generic extensions, has 
> there been a discussion of mechanisms by which VNC servers and clients 
> might determine and negotiate the "fastest" parameters based on the 
> measured performance of the connection? 

I've posted about this before.  Yes, I think that an "automatic"
encoding selection would be a good idea.

> 
> Dynamic optimization of these parameters is probably desirable, 
> particularly in light of the fact that there is much confusion amongst 
> users w.r.t. which encodings are good for which environments. I realize 
> this opens up a big can of worms in deciding whether this is properly a 
> client or server function (and determining agreed-upon general policy for 
> which encodings and settings to use in which circumstances.) I think the 
> logic for this belongs in the server, so that the client can continue to 
> be as simple and stupid as possible per the original design, which 
> supports thin clients quite well. (This approach will serve us well for 
> at least another few years until adequate local compute power and 
> bandwidth are ubiquitous - not all clients are PCs.) 

The problem with putting the logic in the server is that it
has no good way to measure latency or viewer decoding time.
The viewer can use a timer to get a combined value of
<latency>+<encoding time>.  By requesting a very small update
(w=1, h=1), the viewer might be able to get a better latency
value by pushing the encoding time towards zero.  I think the
server is allowed to merge updates, so this might not work.

Total responsiveness optimization will also require the use
of decoding time.  The server can not easily know how long
the CPU on the viewer took to decode an update.  Since the
total response time to the user is:

  <mouse click> + <xmit x,y to server> + <server delivers
   mouse event> + <application responds to mouse> + <server
   encodes screen changes> + <xmit updates to viewer> +
   <viewer decodes changes> + <viewer draws changes>

only the viewer has a chance of easily assembling a total
response time value/average.  This total response time
number will be needed to guess at when to change encodings
and whether a new encoding is really working better than
the previous one.

Of course, the bigger question is *what metric* should
be optimized when selecting the encoding?  Is user response
time the right value?  What about network bandwidth?
By the time a 100 Mb Ethernet link becomes saturated with
RFB traffic and the automatic encoding starts using
stronger compression, other streaming protocols may be
unusable.  So, how well does this approach scale up on
over shared transports?

> 
> I guess this is to some degree a request to let the community know about 
> these proposed extensions in advance of them being carved in stone. VNC 
> should not try to do everything, but it should be able to do everything 
> that is legitimately in its problem domain very well. (A good consensus 
> on the problem domain will prevent problems in the future, too.) I'm sure 
> I'm not the only one wondering how all this is going to happen... 
> 
> Dub 

No doubt this is a good idea.  Right now, no one is actively
working on it, AFAIK.

-- 
Brian 
----------------------------------------------------------------------------
TridiaVNC, the cross-platform, open source, remote control solution.
http://www.TridiaVNC.com/   and   http://www.developVNC.org/
Java VNC Server Demo:
http://www.developVNC.org/logged-in/jVNC-info.html
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------