Date:	Sat, 15 Nov 2008 11:50:42 +0100
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	Leandro Sales <leandroal@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	ian.mcdonald@...di.co.nz, DCCP Mailing List <dccp@...r.kernel.org>
Cc:	netdev@...r.kernel.org
Subject: [RFC] dccp ccid-3: High-res or low-res timers?

I would appreciate some advice and insights regarding the use of
high-resolution timers within a transport protocol, specifically
DCCP with CCID-3 (RFC 5348).

Currently the implementation is in a limbo of high-resolution and
low-resolution code. It is not good, neither here nor there, so
I would like to work on making the interface consistent.

After thinking this through I encountered a number of points
which made me question whether high-resolution timers will lead to
better performance and a cleaner interface.

I'd appreciate comments and input on this, the points are below.

1. Handling unavoidable waiting times
-------------------------------------
 One can not expect that, if the scheduling clock says 'send in x
 microseconds', a packet will indeed leave after x microseconds; due to
 waiting times. An example is in net/dccp/timer.c, when the socket is
 currently locked - we wait for a "small" amount of time:

	bh_lock_sock(sk);
	if (sock_owned_by_user(sk))
		sk_reset_timer(sk, &dp->dccps_xmit_timer, jiffies + 1);
	else
		dccp_write_xmit(sk, 0);
	bh_unlock_sock(sk);


2. Dependency on high-resolution timers
---------------------------------------
 Committing the CCID-3/CCID-4 implementations to using high-resolution
 timers means that the modules can not be built/loaded when the kernel
 does not offer sufficient resolution.

 This has recently made it hard for someone using CCID-3 to find out
 why DCCP would not run, where the cause was that high-resolution timers
 were not enabled in the kernel.


3. Noise in the output
----------------------
When tracking the speed of a car every 10 seconds, there is a lot of variation
in the values, due to stopping at traffic lights, accelerating etc. But when
considering a larger timescale, one can say that the average speed from city
A to city B was xx mph, since the whole journey took 2.5 hours.

The same can currently be observed with X_recv - there is one commit which 
tries to make X_recv as fine-grained as possible, it is labelled "dccp ccid-3:
Update the computation of X_recv",
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=2d0b687025494e5d8918ffcc7029d793390835cc

The result is that X_recv now shows much wider variation, on a small timescale
there is a lot happening. It can best be seen by plotting the X_recv using
dccp_probe. Without this commit the graphs are much 'quieter' and just show
the long-term average.

In TCP Westwood for instance a low-pass filter is used to filter out the 
high-frequency changes in the measurements of the Ack Rate:

"TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links"
Mobicom 2001
http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_papers/2001-mobicom-0.pdf

I'd appreciate opinions on this, as I think 

With regard to CCID-3, it also seems to be be better to revert the above
commit and just use long-term averages.


4. Not sure using high-resolution is the answer
-----------------------------------------------
While a fine-grained timer resolution may be desirable, it is not
necessarily a must. The implementation of rate-based pacing in TCP
(http://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.html) for instance
also used low(er) resolution timers and it worked.

The RFC for CCID-3 (http://www.rfc-archive.org/getrfc.php?rfc=5348) also
does not high-resolution; it supports coarse-grained timestamps (section
6.3 and RFC 4342) and discusses implementation issues when using a 
lower resolution (section 8.3).

The counter-argument could be that CCID-3 is a transport protocol with a
built-in Token Bucket Filter so that similar considerations apply as for
the Qdisc API (net/sched/sch_api.c).

Summing up, I have doubts that basing CCID-3 will bring advantages and
would much rather go the other way and (consistently) use lower resolution.

Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists