[Spice-devel] [PATCH v2 spice-protocol 2/2] Add qos related messages

[David Jaša]

Marc-André Lureau píše v St 18. 04. 2012 v 19:47 +0200:
> Hi
> 
> On Wed, Apr 18, 2012 at 7:34 PM, Marc-André Lureau
> <marcandre.lureau at gmail.com> wrote:
> > It would be
> > -> QOS_QUERY(nbytes)
> > -> nbytes of various messages 1 or n
> > <- QOS_ACK
> 
> Further questions about this, how can the server really determine the
> bandwidth? (I suppose this is the goal)
> 
> There might be data queued on the upstream link, and then latency and
> other factors are affecting the result.
> 
> It could perhaps be more reliable if the messages would be:
> 
> -> QOS_QUERY(nbytes)
> -> nbytes of various messages data
> <- QOS_ACK(N Bps)
> 
> 
> Btw, those messages should be symmetric, so we could measure
> upload/download (it's always fun to reinvent the wheel!)
> 

Just my $0.02: it seems to me that only the time it takes to client (or
receiving side more generally - think about record channel or guest to
client copy & paste) to receive data. If the client time is trustworthy
then it could look like this:

1. sender starts sending data
2. receiver starts receiving and notes t_0
3. throughout the download, the client notes stuff like reordered and
resent packets
4. receiver gets last packet and notes t_1
5. in the last ACK receiver sends t = t_1 - t_0, download speed
variation (if download takes sufficiently long) and packet reordering
rate (which indicate network jitter) and packet loss
--> sending side has all the informations about line quality, summarized

when client time pace is not to be trusted, then:

-> sender starts sending, notes t_0
<- clients sends first ACK right when first packet arrives, server notes
t_1 when the ACK arrives
-> server continues sending data till end of message
<- client sends final ACK, serve notes t_2

t_ping = t_1 - t_0 can be used to determine latency (and jitter when
there are more pings like this available), t_bw = t_2 - t_1 then
determines bandwidth. If t_bw is not significantly larger than t_ping,
the message is too small to determine bandwidth reliably.

David

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24