Subject: [Iccrg] Re: [Tmrg] convergence time
From: [email-masked] (Dirceu Cavendish)
Date: Wed Oct 31 18:01:04 2007

Lachlan,

I dont see a problem in measuring transient interaction - I see an opportunity. If a researcher wishes to evaluate the transient of a single flow, he/she can certainly design an experiment to make sure interactions are avoided. (spacing flows properly, as you mentioned). I find transient interaction effects VERY interesting to study...

The bottom line is: agreeing on X(t) performance metrics instead of x(t) does not LIMIT in any way the expressiveness of experimental results, since we can always reduce X(t) to x(t) by using a single flow...

Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Xiaoliang (David) Wei <[email-masked]>
Cc: tmrg <[email-masked]>; iccrg IRTF list <[email-masked]>
Sent: Wednesday, October 31, 2007 10:18:13 AM
Subject: [Iccrg] Re: [Tmrg] convergence time

Greetings David,

On 28/10/2007, Xiaoliang (David) Wei <[email-masked]> wrote:
>    Another option, to eliminate the dependency to stability and
> timescale, is that we don't study the convergence of current rate.
> Instead, we study the convergence of the aggregate average rate. That is,
> if the instanenous rate of a flow at time t is x(t), we define the
> aggregate average rate of the flow at time t to be
> X(t) = 1/t * sum u=0->t x(u).
> ("sum" can be "integrate" if the time is continous).

Good idea.

> Then we study the convergence of the curve X(t) to the "final value".
> This process might be easier as:
> 1. X(t) is easier to measure because we can just look at the amount we
> have transfered from time 0 to time t;
> 2. X(t) converges even x(t) has a limit-cycle oscillation, so it is less
> sensitive to stability
> 3. If x(t) converges fast, X(t) converges fast too. We can still compare
> the convergence with X(t)
> 4. X(t) does have meaning in user-experience. It measures how long the
> users have to participate in the network to get to the desired rate.

They're all good points.

The main drawback is that  X(t)  converges (much) more slowly, since
it always gives some weight to the early rates.  If we want to observe
the impact of each of several newly arriving flows, we need to space
them out further if we use  X(t)  than we do if we use  x(t), or else
the transients will interact.

The time required to find the "final" value could already be quite
long, especially in the case of Reno, which takes hours to reach
equilibrium on large BDP paths.

What do others think?

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071031/e2afd40d/attachment.html
>From [email-masked]  Wed Oct 31 19:16:45 2007
From: [email-masked] (Lachlan Andrew)
Date: Wed Oct 31 19:16:48 2007
Subject: [Iccrg] Re: [Tmrg] convergence time
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu,

On 31/10/2007, Dirceu Cavendish <[email-masked]> wrote:
> I find transient interaction effects VERY interesting to study...

True.  But they are also complex.  My aim with this roundtable was to
agree on some simple "single numbers" to make comparison between
different people's experiments easier.  If we measure convergence time
as the time for  X(t)  to reach within 20% of its final value, but in
the experiment,  X(t)  never reaches its final value, then we are left
with no numeric measure of the convergence time.

What information will  X(t)  tell us about the interactions that isn't
more apparent from  x(t)?  The benefits David mentioned apply mainly
to the case without interactions.

> The bottom line is: agreeing on X(t) performance metrics instead of x(t)
> does not LIMIT in any way the expressiveness of experimental results, since
> we can always reduce X(t) to x(t) by using a single flow...

I agree that we can get  x(t)  from  X(t)  by differentiating it
(regardless of how many flows).
In terms of "expressiveness", they both carry exactly the same amount
of information, if we want to compare the whole functions, rather than
thresholding thiem.  My question is how we can make that comparison.
Does anyone have any suggestions?

To me, we need to agree on some sort of data reduction, and
thresholding is a simple example.  Thresholding  X(t)  seems more
problematic.  Of course, that problem may go away if there is a better
alternative than thresholding.

Thanks,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Lachlan Andrew)
Date: Wed Oct 31 17:34:24 2007
Subject: [Iccrg] Re: [Tmrg] convergence time
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Andrea,

On 30/10/2007, Andrea Baiocchi <[email-masked]> wrote:
>
> At 13:00 -0700 27-10-2007, Lachlan Andrew wrote:
> >How should we measure the responsiveness of a TCP algorithm?
>
> can it be sensible to look at responsiveness from a point of view
> closer to the user, by measuring the time required to deliver a given
> amount of data Bklg as a function of the value of Bklg? This is a
> curve not a single value, but useful indication could be extracted
> from there (i.e. asymptotic growth rate).

That is a very useful metric for the "efficiency" or "aggressiveness"
of the algorithm.  It is essentially the "flow completion time" metric
that Nandita and Nick have been promoting.

When I spoke of "responsiveness", I meant "response to changes in
network conditions", which is something not captured by the metric you
mention.  Whatever we call them, we need to measure both effects.

> My proposal above suffers from slow start dependence. It could be
> "generalized" (albeit also complicated) by considering the amount of
> time required to deliver one INCREMENT of Bklg, say DeltaB, after an
> amount Bklg0 has already been delivered. As an example, given Bklg0,
> time required to deliver further data DeltaB=alpha*Bklg0, with
> alpha=0.1. Parameters to choose for this measurement are in general
> Bklg0 and alpha. This last measurement could also be normalized to
> the overall time required to deliver Bklg0 amount of data.

That metric is equivalent to the average rate over some interval.  Can
you think of a way to average out the effects of AIMD in that
measurement?  It would either need  alpha  to be quite large, or to be
specially tuned to the time between loss events.  Otherwise, for given
parameters  alpha  and  Bklg0,  an algorithm could alternate between
doing well and doing poorly as the RTT increases, as the interval
moves from (just before a loss) to (just after a loss).

> Thank you for you attention.

Thank you for your input!

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Murari Sridharan)
Date: Tue Oct 30 20:32:03 2007
Subject: [Iccrg] Updated draft
Message-ID: <[email-masked]>

We updated the draft based on input from Lachlan (Thanks). The draft is available at http://www.ietf.org/internet-drafts/draft-sridharan-tcpm-ctcp-01.txt

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071030/0b258bdf/attachment.html
>From [email-masked]  Wed Oct 31 17:18:13 2007
From: [email-masked] (Lachlan Andrew)
Date: Wed Oct 31 17:18:00 2007
Subject: [Iccrg] Re: [Tmrg] convergence time
In-Reply-To: <Pine.GSO.4.58.0710282328230.23481@inky>
References: <[email-masked]>
	<Pine.GSO.4.58.0710282328230.23481@inky>
Message-ID: <[email-masked]>

Greetings David,

On 28/10/2007, Xiaoliang (David) Wei <[email-masked]> wrote:
>     Another option, to eliminate the dependency to stability and
> timescale, is that we don't study the convergence of current rate.
> Instead, we study the convergence of the aggregate average rate. That is,
> if the instanenous rate of a flow at time t is x(t), we define the
> aggregate average rate of the flow at time t to be
> X(t) = 1/t * sum u=0->t x(u).
> ("sum" can be "integrate" if the time is continous).

Good idea.

> Then we study the convergence of the curve X(t) to the "final value".
> This process might be easier as:
> 1. X(t) is easier to measure because we can just look at the amount we
> have transfered from time 0 to time t;
> 2. X(t) converges even x(t) has a limit-cycle oscillation, so it is less
> sensitive to stability
> 3. If x(t) converges fast, X(t) converges fast too. We can still compare
> the convergence with X(t)
> 4. X(t) does have meaning in user-experience. It measures how long the
> users have to participate in the network to get to the desired rate.

They're all good points.

The main drawback is that  X(t)  converges (much) more slowly, since
it always gives some weight to the early rates.  If we want to observe
the impact of each of several newly arriving flows, we need to space
them out further if we use  X(t)  than we do if we use  x(t), or else
the transients will interact.

The time required to find the "final" value could already be quite
long, especially in the case of Reno, which takes hours to reach
equilibrium on large BDP paths.

What do others think?

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Canada Pharmacy)
Date: Thu Oct 25 01:30:37 2007
Subject: [Iccrg] Lowest Price Guarantee
Message-ID: <[email-masked]>

A non-text attachment was scrubbed...
Name: not available
Type: text/
Size: 300 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071024/ad04936a/attachment.bin
>From [email-masked]  Thu Oct 25 20:23:32 2007
From: [email-masked] (Mark Allman)
Date: Thu Oct 25 20:25:57 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Nobody is saying that it is safe to have a rule like "use RTO=200ms".
> However, it should be "safe" to trust the RTO calculations, unless
> they predict a very small timeout.  If that is not the case, we should
> IMO fix the RTO calculations, rather than simply ignoring them and
> using a 1s minimum.

The safeness of the RTO is the exponential backoff of the RTO.  IMO.

As I have noted before I think the minimum RTO represents a knob to make
a tradeoff between quicker RTOs and spurious RTOs.  I don't think
determining the correct min RTO is a simple question to answer without
experiments.  (See our 1999 SIGCOMM paper on estimating path properties
and my previous note on the subject for more information.)

> > I'd also wonder why tuning the min RTO is needed (except to recover
> > from quirky packet loss in the few initial RTTs), since modern TCP
> > does a pretty good job of recovering packets without needing timer
> > tuning.
> 
> I'm not sure what you mean by "without needing timer tuning".  RTO
> tuning has been part of TCP since the '80s.

I took Gorry's comment to mean that we have designed a number of loss
recovery techniques that work independently of the RTO (e.g., fast
retransmit, newreno, sack, ...) and so his presumption seems to be (and
my assumption is) that these techniques should be fixing the lion's
share of the loss.  Therefore, trying to somehow 'optimize' the RTO
seems somehow a bit dubious.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071025/a28fa576/attachment.bin
>From [email-masked]  Sat Oct 27 21:00:01 2007
From: [email-masked] (Lachlan Andrew)
Date: Sat Oct 27 21:10:11 2007
Subject: [Iccrg] convergence time
Message-ID: <[email-masked]>

Greetings all,

With the TCP evaluation round table just under two weeks away, let's
keep the discussions moving.  It would be great for people to start
threads on whatever issues they think we should agree on. Even if
you're not coming in person or through VRVS, feel free to start a
thread.

How should we measure the responsiveness of a TCP algorithm?  One way
is to measure "convergence time" as the time after a step change in
traffic until rate is within x% of its final value.

If we agree on that, we need to decide:

- What should x be?  I think it is not very critical, as long as we
agree on it.  If it is too low (like within 10%), it becomes too
sensitive to how we measure rates.  If it is too high (like within
50%), it doesn't capture whole convergence process.  Is 30% OK?

- How do we determine the "final value" of rate?  If everything is
symmetric, we could just take is at the "fair" (equal) rates, but I
think we should define it independently for fairness, for those cases
in which flows never reach equal rates.  For experiments with just one
step change followed by a long period of "steady state" (possibly with
cross traffic coming and going), we can just average over a period "a
long time" after the event.  How long should that be?  It could be
something like "when the rate of change has dropped to 5% of the
original rate of change" or some such.

- What timescale should we average the "current" rate over?  Rates
vary due to AIMD and cross traffic, as well as the convergence
process.  For loss-based protocols, including hybrid loss+delay, we
could base it on the rate (or window) just before or just after a loss
event.  For non-loss-based protocols, we could simply average over one
RTT.  Thoughts?

- The convergence time depends on setting, such as the number of
competing flows, and the RTT.  Should we specify a few settings
specifically for determining "the convergence speed of the algorithm",
or should we just say how to measure convergence time for each
experiment?

- The rise time of a single flow to an empty systems is not very
interesting, because it many measures the impact of slow start.  Is it
interesting to consider the response of one existing flow to one new
flow?  An alternative is to consider time to settle when a flow
*departs*, although that mainly measure the aggressiveness of the
protocol, rather than its responsiveness.

- We need to make these repeatable.  That is particularly hard with
cross traffic.  Should we specify a minimum number of runs to average
over?  If so, there is a tradeoff between accuracy and time to
complete the tests.  Would averaging over 5 tests be enough?

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Lachlan Andrew)
Date: Thu Oct 18 21:46:38 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Gorry,

On 18/10/2007, Gorry Fairhurst <[email-masked]> wrote:
>
> I'm surprised that anyone would judge "200ms" as "safe" for general
> deployment, and would like to understand why they believe this is desirable.

TCP has a mechanism for determining the timeout, based on the mean RTT
and the mean deviation.  If the minimum RTO is 1s as per the RFC, this
value is carefully calculated, and then ignored, since 1s will be used
instead.

Nobody is saying that it is safe to have a rule like "use RTO=200ms".
However, it should be "safe" to trust the RTO calculations, unless
they predict a very small timeout.  If that is not the case, we should
IMO fix the RTO calculations, rather than simply ignoring them and
using a 1s minimum.

> I'd also wonder why tuning the min RTO is needed (except to recover from
> quirky packet loss in the few initial RTTs), since modern TCP does a
> pretty good job of recovering packets without needing timer tuning.

I'm not sure what you mean by "without needing timer tuning".  RTO
tuning has been part of TCP since the '80s.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Gorry Fairhurst)
Date: Thu Oct 18 20:01:59 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I'm surprised that anyone would judge "200ms" as "safe" for general 
deployment, and would like to understand why they believe this is desirable.

I'd also wonder why tuning the min RTO is needed (except to recover from 
quirky packet loss in the few initial RTTs), since modern TCP does a 
pretty good job of recovering packets without needing timer tuning.

Gorry

Lachlan Andrew wrote:
> Greetings Ian,
>
> Since you've had no replies, here's my $0.02 worth.
>
> I haven't seen any specific research on that.
>
> Linux currently uses much higher precision timestamps than the old BSD
> implementations to which the RFC refers, so it shouldn't really be an
> issue.
>
> The fact that Vegas works in Linux also shows that its timestamping
> doesn't have systematic errors that would require a more conservative
> timeout.
>
> I agree that 1s is a terribly high minimum.  It looks like time for an
> update to RFC 2988 :)
>
> Cheers,
> Lachlan
>
> On 29/08/2007, Ian McDonald <[email-masked]> wrote:
>   
>> After some discussion on the Linux networking list I thought I'd ask
>> the question here.
>>
>> In RFC 2988 Section 2.4 says:
>>    (2.4) Whenever RTO is computed, if it is less than 1 second then the
>>          RTO SHOULD be rounded up to 1 second.
>>
>>          Traditionally, TCP implementations use coarse grain clocks to
>>          measure the RTT and trigger the RTO, which imposes a large
>>          minimum value on the RTO.  Research suggests that a large
>>          minimum RTO is needed to keep TCP conservative and avoid
>>          spurious retransmissions [AP99].  Therefore, this
>>          specification requires a large minimum RTO as a conservative
>>          approach, while at the same time acknowledging that at some
>>          future point, research may show that a smaller minimum RTO is
>>          acceptable or superior.
>>
>> Given that Linux, BSD etc use 200 milliseconds, not 1 second I am
>> wondering whether there has in fact been any research done as
>> mentioned in last sentence. It seems a very high timeout especially on
>> two locally connected devices.
>>     
>
>
>   

From: [email-masked] (Lachlan Andrew)
Date: Thu Oct 18 16:21:02 2007
Subject: [Iccrg] TCP evaluation suite round-table
Message-ID: <[email-masked]>

Greetings all,

(I sent this invitation to the  tmrg  mailing list awhile ago, but
there are probably people here who are also interested, but not on
that list.)

In order to compare different TCP algorithms, it is important to have
a standardized set of tests.  On 8-9 November, we're having a "round
table" discussion to make a small step in that direction.

We won't try to answer things like "what fairness metric is best", but
we can agree on some basic parameters.  The situation we're trying to
avoid is:

Group A finds that at  500Mbps,  flow 1 reaches 10% of its final
throughput after 30s
Group B finds that at  622Mbps,  flow 1 reaches  20% of its final
throughput after 20s

I'll try to have live video-conferencing via VRVS
<http://www.vrvs.org/Doc/faq.html> so that those who can't come in
person can still participate.  Unfortunately, our videoconferencing
room is small, and so physical attendance will probably be limited to
a dozen or so people.

**** If you're interested, please let me know in the next week or two. ***

As basic goals, I'd like to come away from the roundtable with:
- a set of bandwidths that are of interest, say 10, 155, 622, 2500 Mbps
- a set of buffer sizes that are of interest, like BDP or 16384 packets
- a set of distributions of RTT that are of interest
- an agreed notion of "convergence time"
           -- e.g., "the average over period x is within y% of the
final average
- an agreed notion of "time to converge to fairness"
           -- e.g., "the ratio of averages over period x is within y%
of the final ratio"
           -- should this metric depend on the final ratio achieved?
- an agreed notion of "intraflow variability"
          -- e.g., what timescales are of interest?
- an agreed set of traffic models for background traffic

Injong has added to that list:
- a measure of total link utilization
- fluctuation in utilization due to fluctuation in background traffic.
- What is the per-flow fair bandwidth share?

We've started some preliminary discussions on the TMRG mailing list to
sort out the "easy" issues, leaving time at the round table to discuss
the more contentious ones.  These are summarized at
<http://wil.cs.caltech.edu/mwiki/index.php?title=Benchmarking_parameters>.

It would be good to have a common set of scenarios which could be
tested by simulation, emulation and real networks.  Obviously, the
simulation is the most flexible, and so it may have a larger set of
tests, but we can at least simulate the emulated cases.

Ulterior motive: I'd like people also to simulate/emulate the
scenarios that can also be tested on WAN-in-Lab :)

I hope that we can get enough agreement from enough people to make
this effective.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Lawrence Stewart)
Date: Wed Oct 10 04:37:45 2007
Subject: [Iccrg] Software for FreeBSD TCP R&D: SIFTR v1.1.4 and DPD v1.0 released
Message-ID: <[email-masked]>

Hi All,

Further to the recent forwarded email from Grenville regarding SIFTR, we 
just wanted to give you a quick heads up regarding the availability of a 
new SIFTR (Statistical Information for TCP Research) version and the 
debut release of DPD (Deterministic Packet Discard).

SIFTR v1.1.4 addresses a couple of issues, one of which is applicable to
users of SIFTR in FreeBSD 7-CURRENT. Read the changelog and readme for
more information.

DPD is a new FreeBSD kernel module we developed to further aid us in our
ongoing TCP research. It allows for the deterministic dropping of TCP
packets from within the FreeBSD kernel via a simple sysctl interface.
This is particularly useful for anyone that is interested in observing
TCP reacting to packet loss events (e.g. congestion control
researchers). Being able to drop the same packet(s) across multiple
tests allows for simpler comparisons of TCP behaviour. We've found it
particularly useful in evaluating and observing the behaviour of
different congestion control mechanisms, and hope it may be of use to
others out there. Please refer to the DPD readme for more in-depth
information.

The software and documentation is freely available under a BSD licence from:

http://caia.swin.edu.au/urp/newtcp/tools.html

We would be very happy to hear from anyone regarding bugs and
suggestions as well.

Cheers,
Lawrence

http://caia.swin.edu.au

From: [email-masked] (Michael Welzl)
Date: Thu Oct  4 11:38:29 2007
Subject: [Iccrg] Next meeting
Message-ID: <[email-masked]>

Dear all,

As announced during the last two meetings, the next
meeting is planned to be held in conjunction with
PFLDNet 2008 in Manchester, GB, hosted by Richard
Hughes-Jones from Manchester University.

The reason for this combination is the fact that the
communities going to this workshop and going to ICCRG
meetings tend to overlap; moreover, this meeting will
be a nice chance for our European members to get
involved.

PFLDNet is in preparation, the CFP will be announced
soon (I'll forward it to this list too). It will be
held Wed-Fri 5-7 March 2008, so our meeting would be
on Mon-Tue 3-4 March 2008.

The intention of this message is to give you an early
notice about the dates and location, and to see if
there are major date conflicts. Since I'm sure that
we cannot find ideal dates for everyone, I guess it
would be better not to discuss conflicts on the
list; if you have a conflict with these dates but
would nevertheless like to attend the meeting, please
send a note to the Wes at [email-masked] and me.

We are aware that it's a bit inconvenient to hold a meeting
in Europe just a week before an IETF meeting in the
states - on the other hand, this week was already chosen
for PFLDNet based on avoidance of several other conflicts,
so it's really the best that we could come up with.

What we could offer is to present a follow-up / review of
what happened in Manchester at another ICCRG meeting
the next week in Philadelphia that could be attended by
the people who didn't make Manchester; most probably,
Wes will be able to come to Philadelphia.

If you write to us because of a date conflict, please
also let us know what you think of this idea of an
additional meeting.

Thanks!

Cheers,
Michael

--------------------------------------------

PS: things have been a bit silent recently regarding
the two high-speed tcp proposals under evaluation,
CTCP and CUBIC. As we wrote on their respective pages
(see our group's page), their status is:

CTCP:
2 volunteers accepted to review the draft. They are not reviewing it
yet, as we're awaiting an update from the authors.

CUBIC:
Draft received, call for reviewers sent to the ICCRG list.

... so we're still waiting for people to look at CUBIC;
Please consider volunteering!