Subject: [Iccrg] Answer to MulTFRC reviews
From: [email-masked] (Lachlan Andrew)
Date: Mon Jan 25 22:50:38 2010

Thanks for the reply, Michael.

I'll delay responding in the hope that someone else will express an opinion.

Cheers,
Lachlan

2010/1/25 Michael Welzl <[email-masked]>:
> On Jan 22, 2010, at 1:33 AM, Lachlan Andrew wrote:
>> 2010/1/22 Michael Welzl <[email-masked]>:
>>> On Jan 21, 2010, at 1:05 AM, Lachlan Andrew wrote:
>>>> 2010/1/20 Michael Welzl <[email-masked]>:

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] (Michael Welzl)
Date: Mon Jan 25 10:59:06 2010
Subject: [Iccrg] Answer to MulTFRC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

!!!

EDIT: I'm very sorry, there was a leftover sentence which
I started to write and then overlooked in my previous email:

!!!

>> A lot of our disagreement relates to the source of loss.  If the only
>> loss is self-induced loss by long-lived flows, then I agree with many
>> of your statements.  However loss is often caused by short-lived  
>> flows
>> slow-starting until they force a loss.  I'll explain how that matters
>> in a couple of the cases below.
>
> Okay; I also think that some of our disagreement...

please ignore this line above: I agree with what you say
and that's all.

Very sorry for that!

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Mon Jan 25 10:52:05 2010
Subject: [Iccrg] Answer to MulTFRC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Sorry for the delay...

On Jan 22, 2010, at 1:33 AM, Lachlan Andrew wrote:

> Greetings Michael / all,
>
> A lot of our disagreement relates to the source of loss.  If the only
> loss is self-induced loss by long-lived flows, then I agree with many
> of your statements.  However loss is often caused by short-lived flows
> slow-starting until they force a loss.  I'll explain how that matters
> in a couple of the cases below.

Okay; I also think that some of our disagreement...

>
> 2010/1/22 Michael Welzl <[email-masked]>:
>> On Jan 21, 2010, at 1:05 AM, Lachlan Andrew wrote:
>>> 2010/1/20 Michael Welzl <[email-masked]>:
>
>>> My point was that standard TCP is   sufficiently   aggressive in a  
>>> LAN
>>> environment.
>>
>> Not necessarily - this depends on the buffer size:
>
> If the BDP is small, the only way for TCP not to get a high throughput
> (after slow start) is for the loss rate to be quite high.  If the
> buffer isn't enough to prevent loss of the order of one packet in 100,
> then making TCP "the same but more aggressive" just makes life worse
> for loss-sensitive applications.

Well - if there is only one flow on the bottleneck (consider
the not so unusual situation of a user watching a video over
the Internet, with the bottleneck being his/her home access
connection), and the buffer is very small, then the average
utilization of this link declines with standard TCP, with a
lower end of only 75%.

More generally, this is true whenever the buffer is very
small compared to the BDP, leading to my argument in
favor of a mechanism that can reach a higher percentage.

> If the buffer is sufficiently large, then the limitation on TCP is
> from bursty cross-traffic.  Since it only takes TCP a few RTTs (a few
> ms on a LAN) to recover a BDP-sized window, I'd argue that TCP is
> "sufficiently aggressive" to handle flows which start occasionally.

I agree. Note, however, that we are
1) not proposing a TCP replacement
2) not proposing a mechanism that is under all circumstances
more aggressive than TCP as its only benefit. MulTFRC covers
a wide range of values for N (the number of emulated flows),
including values between 0 and 1, i.e. it can let its users reduce
the aggression below that of TCP. I think that this can be useful
too, e.g. if I'm happy enough with the video quality even if N < 1
and want to download something fast at the same time.

>> How do you define "too aggressive"?
>
> Nothing precise.  Perhaps "transmitting so many packets into the
> network that the incremental damage we do to other traffic is greater
> than the incremental benefit to ourselves".  In this case, we get no
> additional benefit from keeping the average (not peak) buffer
> occupancy high, but we cause problems for others.

...the problem being that "damage" and "benefit" are extremely vague
terms. That was my point: it very much depends on what users want.
If I'm happy with voice quality while a video is transmitted with
MulTFRC with N=6 in the background, then that's fine. Anyhow my
main argument is that the ability to change N (as opposed to the fixed  
N=1
value that standard TFRC gives you) is useful.

>> It causes delay, by letting the queue overflow, which, as you
>> rightly say, is true for any loss-based algorithm.
>
> Loss only requires the peak buffer occupancy to be high -- not the  
> average.

Yes - and so...?

>> I would argue that, while this is an interesting study, trying
>> to optimize a mechanism for it is to optimize it for a very
>> poorly tuned special circumstances
>
> You're right that we shouldn't optimise for it, but we should consider
> it.  It is just an example of a case when making TCP more aggressive
> is not appropriate.

I can easily take a case
(fig. 3 in L. Stewart, G. Armitage, A. Huebner, "Collateral Damage:
The Impact of Optimised TCP Variants On Real-time Traffic Latency
in Consumer Broadband Environments", IFIP/TC6 NETWORKING 2009,
Aachen, Germany, 11-15 May 2009.)
out of Lawrence's investigation that you mentioned to argue
against what you say here: HTCP appears to sometimes
cause less (in other cases, at most as much) extra delay for
other flows than standard TCP does. Yet, it is *more* aggressive.

So, we would first have to investigate what the delay impact of
MulTFRC really is before making a judgement like that. I'd agree
that this is a useful investigation to do, but I'd also argue against
making this a reason to accept or not accept publication of MulTFRC
as an Experimental RFC, or even to make a general recommendation
about the setting of N, because of what we both agree on above:
that the case is worth considering, but not optimising for.

>> where the only real
>> solution is to throw all non-delay-based schemes away.
>
> As an aside, there's a big difference between "delay-based schemes"
> and schemes which detect persistently high queueing delay.  I strongly
> believe that new-generation congestion control should try to use all
> available information, including both loss and delay.  Occasional
> peaks in delay may be spurious, and so purely delay-based schemes are
> problematic.  However, if the delay is consistently high and reducing
> our window does not reduce our throughput, then I think we have no
> excuse not to reduce our window.

I tend to agree with your view, but would not want to reject,
say, CUBIC (heh, or MulTFRC!  ;-)  )  on this basis. Also note
that not everyone agrees that delay (or fluctuations thereof)
is a reliable enough source of information, cf. the discussion
that we had about this in TMRG.

>> Indeed, the buffer size is the problem, and I don't see how
>> this fact changes by saying "if the BDP were higher then the
>> size of the buffer would be fine" - because it just isn't higher,
>> and if it was, the problem would disappear, both with
>> MulTFRC and with all other loss-based mechanisms.
>
> The BDP *is* higher on some paths than on others.  The buffer at a
> link is always going to be too big for some paths and too small for
> others.  We don't need the case to be as extreme as current ADSL links
> for that to remain true.

Okay, true - but my answer related to your ADSL example which
we have discussed above, and the larger the BDP, the less
of a problem this becomes (because the buffer would then
have to be even larger to cause the problem that we're talking
about). In other words, the case doesn't get more interesting
if we look at larger BDPs - it shifts in favor of MulTFRC with
a large N  :-)

>>>> upper limit, which we recommend to have.
>>>
>>> That limits the scalability.  It may buy us an extra generation of
>>> Ethernet (increase aggressiveness by a factor of 10 to match going
>>> from GbE to 10GbE), but doesn't address the inherent scalability
>>> problem.
>>
>> I don't get this, most probably it's a misunderstanding.
>> A limit of, e.g., N=6 emulated flows, will always give you
>> at least 95% link utilization or more, irrespective of the BDP.
>
> We get 95% utilisation if the only loss is self-induced.  However, if

Sorry, yes - I wrote "at least", meaning "irrespective of the
queue length". Of course, that is only the "I am the only one"
(i.e. self-induced loss) case.

> the BDP is large and there a loss because another flow slow-started
> and then disappeared, then it will take a long time to recover.

> That was always the fundamental problem with Reno on high BDP links,
> wasn't it?  Without cross traffic, even small buffers give 75%
> utilisation for arbitrarily large BDPs under Reno, but it takes hours
> to recover from a few seconds' cross traffic on some hop.

Agreed. Being more aggressive, more flows (and, similarly,
MulTFRC with N>1 ) recover faster, but a fixed value of N
may be too much for some links (case 1) and not enough for
other (case 2).

Case 1: I don't believe this with N=6 because, pragmatically,
from practical experience that I and many others have,
6 TCP flows have worked well even under very poor conditions.
I have personally 6 and more parallel flows to download files
since the early 90's, and the number of downloads as well
as different network conditions that I tried over the years
is surely enough to give a statistically sound result, even
without a diagram showing it   :-)

Case 2: This is very obvious, I believe, and it's also why we're
not in the least suggesting MulTFRC as a new TCP variant - for
the same reason why noone has ever written a paper suggesting
MulTCP with N > 1 instead of e.g. CUBIC, HTCP etc I suppose  :-)

>>> Of course, for an experimental RFC it need not be the very best
>>> solution, but receiving that stamp is a strong endorsement.  I'd be
>>> more in favour of a rate-based version of one of the new-generation
>>> algorithms already before the ICCRG (C-TCP, CUBIC or H-TCP) or  
>>> LEDBAT.
>>> Once simulation/test-bed studies have shown which of the four  
>>> options
>>> seems most promising for "new TFRC", we can set the best one loose  
>>> on
>>> the internet.
>>
>> Now that really makes no sense to me, as MulTFRC is
>> not a TCP variant, and by no means meant to be one.
>> Being slowly reactive, yet having a smooth sending rate
>> (which most TCP applications wouldn't care about),
>> it is just not designed to replace Reno, C-TCP, CUBIC,
>> H-TCP etc. You're comparing apples with oranges here.
>
> I agree that MulTFRC is not a TCP variant, but it is a congestion
> control algorithm.  I though it's aim was to be a rate-based companion
> to MulTCP.

I greatly prefer to see it as an extension of TFRC in the
spirit of MulTCP. That is a major difference: MulTCP is
known not to work well and hasn't been studied as
deeply as TFRC. It is also not designed for multimedia
applications (which want a smooth rate), as TFRC is.

> My argument is that MulTCP has not yet (to my knowledge) been assessed
> by the ICCRG, but that the other congestion control algorithms that I
> mentioned have.  If we are going to let a new rate-based congestion
> control algorithm loose, we SHOULD (not MUST) choose one based on a
> carefully-evaluated window-based algorithm in preference to a
> less-well evaluated one.  That is, the draft should make a case why
> rate-based "equivalents" of the approaches taken by CUBIC, C-TCP or
> H-TCP are not suitable.

No, because TFRC has been evaluated in depth, and MulTFRC is really
nothing but a minor variation of it. What we have done is to (quite
thoroughly, I would say) show that it can act like N TFRCs in parallel,
with a great range of possible values for N, including 0<N<1, while
retaining TFRC's original properties even better than multiple real
TFRCs do.

> I wasn't suggesting that we use the window-based algorithms themselves
> in DCCP.  I was suggesting that we do for them what you have done for
> MulTCP**, and then compare all of the results by simulation/testbed
> before taking the step of endorsing MulTFRC as experimental.

We have plenty of results showing the above, from simulations, and
real-life tests in a local testbed as well as across the Internet. Some
of these results are documented in our CCR paper, and many
more are in Dragana's thesis which we can shortly make available.

> The logic behind TFRC was that the rate-based and window-based flows
> should behave similarly in response to network conditions.  Given
> that, we should make next-generation rate-based flows behave similarly
> to next-generation window-based flows.  Why experiment with MulTFRC if
> MulTCP isn't going to be deployed?

Because MulTCP is 1) not working too well, and 2) rather pointless.
CUBIC et al do a better job than MulTCP at what MulTCP is aiming at,
which is not the same as what (Mul)TFRC is aiming at.

> **That is, we should say "given this pattern of loss, what would the
> window/RTT be?" and set the rate accordingly.

It is set accordingly, as shown in numerous results that Dragana
has produced, where "what would the window/RTT be" is
in fact translated into "what would the behavior of standard TCP be".
There's a ton of diagrams in her thesis with loss on the x-axis, and
various different loss patterns too.

Cheers,
Michael

From: [email-masked] (Xiaoming Fu)
Date: Fri Jan 22 08:38:57 2010
Subject: [Iccrg] CFP: IWQoS 2010
Message-ID: <[email-masked]>

Apologies if you receive multiple copies.

--------------------------------------------------------------------------------------------------------
18th IEEE International Workshop on Quality of Service (IWQoS 2010)
--------------------------------------------------------------------------------------------------------
June 16-18, 2010, Tsinghua University, Beijing, China
http://www.ieee-iwqos.org/2010/cfp.html

Improving quality of service (QoS) in both networks and end systems
has been a long lasting research focus worldwide. The
seventeen-year-long success of IWQoS has established it as a highly
reputable forum to present novel ideas on all research subjects related
to QoS. While QoS research for future generations of wired and wireless
networks continues to captivate much interest, recent exploration of
data centers, virtualization, cloud computing, industrial communication,
and ?green? computing has motivated a new wave of research interest in
QoS and its related metrics such as Quality of Experience (QoE) and
Quality of Protection (QoP). The scope of IWQoS 2010 covers both
theoretical and experimental research on QoS related issues such as
survivability, availability, reliability, security, privacy, pricing,
resource provisioning and management, user experience, and system
performance guarantees. Topics of interest include QoS issues in (but
not limited to) the following areas:

     * Data centers, virtualization and cloud computing
     * Energy saving in networks and end systems; IT technologies to
       reduce energy consumption in applications
     * Protection, experience, security and privacy
     * System dependability, availability; resilience and robustness to
       faults and DoS attacks
     * Scheduling, resource management, queue management, admission
       control; traffic engineering approaches and tools for provisioning
       and evaluation
     * Quality evaluation metrics and methodologies; application-aware
       QoS parsing, identification and control
     * Measurement, evaluation, adaptation and verification
     * Network operations, pricing and billing, network and service
       management
     * Architectures and protocols for IP and WDM networks, overlay and
       peer-to-peer networks; wireless ad hoc, mesh, and sensor networks
     * Design for the future Internet

Paper Submission Guidelines: IWQoS invites submission of manuscripts
with original research results that have not been previously published
or that are not currently under review by another conference or journal.
Submissions will be judged based on originality, significance, interest,
clarity, relevance, and correctness. Paper submissions should be no
longer than 9 single-spaced, double-column pages with font-size of 10.
Papers must be submitted electronically as PDF files through the EDAS
system (http://edas.info/N8541). All submitted papers will be subject to
peer reviews by Technical Program Committee members and other experts in
the field. IWQoS aims at rapid dissemination of research results. For
fast turnaround in the review process, a short review and publication
cycle is designed, with the submission deadline as close to the workshop
as the publisher allows.

The proceedings will be published in IEEE Xplore and EI indexed.
However, IEEE reserves the right to exclude a paper from distribution
after the conference (e.g., removal from IEEE Xplore) if the paper is
not presented at the conference.

*IMPORTANT DATES*
---------------------------
Paper submission deadline: *Feb. 8, 2010*
Notification of accept: April 5, 2010
Camera-ready papers: April 23, 2010

*Technical Program Committee*
-------------------------------------------

Abhishek Chandra, University of Minnesota, USA
Amund Kvalbein, Simula Research Laboratory, Norway
Baochun Li, University of Toronto, Canada
Burkhard Stiller, University of Zurich, Switzerland
Byrav Ramamurthy, University of Nebraska-Lincoln, USA
Cheng-Zhong Xu, Wayne State University, USA
Carlos Calafate, Technical University of Valencia, Spain
Gang Feng, University of Electronic Science and Technology of China, China
David Yau, Purdue University, USA
Dan Marinescu, University of Central Florida, USA
Edmundo Monteiro, University of Coimbra, Portugal
Georgios Karagiannis, University of Twente, The Netherlands
Haining Wang, College of William and Mary, USA
Himabindu Pucha, IBM ARC, USA
Iordanis Koutsopoulos, UTH, Greece
Jiangchuan Liu, Simon Fraser University, Canada
Joel Rodrigues IT, University of Beira Interior, Portugal
John Chi Shing Lui, The Chinese University of Hong Kong, Hong Kong
Martin Reisslein, Arizona State University, USA
Matthew Caesar, University of Illinois at Urbana-Champaign, USA
Narasimha Reddy, Texas A & M University, USA
Oliver Hohlfeld, TU Berlin, Germany
Pascal Lorenz, University of Haute Alsace, France
Patrick Pak-Ching Lee, The Chinese University of Hong Kong, Hong Kong
Qun Li, College of William and Mary, USA
Rade Stanojevic, Telefonica Research, Spain
Sridhar Machiraju, Google, USA
Srihari Nelakuditi, University of South Carolina, USA
Steve Uhlig, TU Berlin/T-labs, Germany
Torsten Braun, University of Bern, Switzerland
Vasilios Siris, ICS-FORTH / Athens University of Economics and Business,
Greece
Weiyi Zhang, North Dakota State University, USA
Xiuzhen Cheng, George Washington Univ., USA
Xue Liu, McGill University, Canada
Yan Chen, Northwestern University, USA
...

-- 
Xiaoming Fu, http://user.informatik.uni-goettingen.de/~fu

From: [email-masked] (Lachlan Andrew)
Date: Fri Jan 22 00:04:39 2010
Subject: [Iccrg] Answer to MulTFRC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael / all,

A lot of our disagreement relates to the source of loss.  If the only
loss is self-induced loss by long-lived flows, then I agree with many
of your statements.  However loss is often caused by short-lived flows
slow-starting until they force a loss.  I'll explain how that matters
in a couple of the cases below.

2010/1/22 Michael Welzl <[email-masked]>:
> On Jan 21, 2010, at 1:05 AM, Lachlan Andrew wrote:
>> 2010/1/20 Michael Welzl <[email-masked]>:

>> My point was that standard TCP is ? sufficiently ? aggressive in a LAN
>> environment.
>
> Not necessarily - this depends on the buffer size:

If the BDP is small, the only way for TCP not to get a high throughput
(after slow start) is for the loss rate to be quite high.  If the
buffer isn't enough to prevent loss of the order of one packet in 100,
then making TCP "the same but more aggressive" just makes life worse
for loss-sensitive applications.

If the buffer is sufficiently large, then the limitation on TCP is
from bursty cross-traffic.  Since it only takes TCP a few RTTs (a few
ms on a LAN) to recover a BDP-sized window, I'd argue that TCP is
"sufficiently aggressive" to handle flows which start occasionally.

>> One example where standard TCP is too aggressive is in highly-buffered
>> ADSL links. ?(You could argue that the problem is the size of the
>> buffer rather than the fact that the BDP is low, but if the BDP were
>> higher then that size of buffer would be fine.) ?The same is true of
>> basically any loss-based algorithm, although Lawrence Stuart here at
>> Swinburne showed that H-TCP's concave increase actually causes lower
>> average queueing than Reno in these cases.
>
> How do you define "too aggressive"?

Nothing precise.  Perhaps "transmitting so many packets into the
network that the incremental damage we do to other traffic is greater
than the incremental benefit to ourselves".  In this case, we get no
additional benefit from keeping the average (not peak) buffer
occupancy high, but we cause problems for others.

> It causes delay, by letting the queue overflow, which, as you
> rightly say, is true for any loss-based algorithm.

Loss only requires the peak buffer occupancy to be high -- not the average.

> Having been
> a part of it at Swinburne myself, I happen to know Lawrence's
> investigation quite well ?:-)

True.  It was some gratuitous advertising of Lawrence's work to others
on the list...

> I would argue that, while this is an interesting study, trying
> to optimize a mechanism for it is to optimize it for a very
> poorly tuned special circumstances

You're right that we shouldn't optimise for it, but we should consider
it.  It is just an example of a case when making TCP more aggressive
is not appropriate.

<soapbox>
This relates to a point I made on e2e recently.  People have said that
the strength of IP is that it runs over a wide range of existing
networks -- it is an *inter*network protocol.  These links are out
there.  If I asked for a show of hands of who on this list has an
ADSL/cable connection with a large buffer, I think it would be the
majority.  Buffers don't exist solely for the benefit of TCP -- they
existed before Tahoe -- and I don't see that we in the layer-4
community can ignore the decisions that are being made at other
layers.  If we didn't have the problem of designing congestion control
to work over the network that is "out there", then we'd do the design
very differently.
</soapbox>

> where the only real
> solution is to throw all non-delay-based schemes away.

As an aside, there's a big difference between "delay-based schemes"
and schemes which detect persistently high queueing delay.  I strongly
believe that new-generation congestion control should try to use all
available information, including both loss and delay.  Occasional
peaks in delay may be spurious, and so purely delay-based schemes are
problematic.  However, if the delay is consistently high and reducing
our window does not reduce our throughput, then I think we have no
excuse not to reduce our window.

> Indeed, the buffer size is the problem, and I don't see how
> this fact changes by saying "if the BDP were higher then the
> size of the buffer would be fine" - because it just isn't higher,
> and if it was, the problem would disappear, both with
> MulTFRC and with all other loss-based mechanisms.

The BDP *is* higher on some paths than on others.  The buffer at a
link is always going to be too big for some paths and too small for
others.  We don't need the case to be as extreme as current ADSL links
for that to remain true.

>>> upper limit, which we recommend to have.
>>
>> That limits the scalability. ?It may buy us an extra generation of
>> Ethernet (increase aggressiveness by a factor of 10 to match going
>> from GbE to 10GbE), but doesn't address the inherent scalability
>> problem.
>
> I don't get this, most probably it's a misunderstanding.
> A limit of, e.g., N=6 emulated flows, will always give you
> at least 95% link utilization or more, irrespective of the BDP.

We get 95% utilisation if the only loss is self-induced.  However, if
the BDP is large and there a loss because another flow slow-started
and then disappeared, then it will take a long time to recover.

That was always the fundamental problem with Reno on high BDP links,
wasn't it?  Without cross traffic, even small buffers give 75%
utilisation for arbitrarily large BDPs under Reno, but it takes hours
to recover from a few seconds' cross traffic on some hop.

>> Of course, for an experimental RFC it need not be the very best
>> solution, but receiving that stamp is a strong endorsement. ?I'd be
>> more in favour of a rate-based version of one of the new-generation
>> algorithms already before the ICCRG (C-TCP, CUBIC or H-TCP) or LEDBAT.
>> Once simulation/test-bed studies have shown which of the four options
>> seems most promising for "new TFRC", we can set the best one loose on
>> the internet.
>
> Now that really makes no sense to me, as MulTFRC is
> not a TCP variant, and by no means meant to be one.
> Being slowly reactive, yet having a smooth sending rate
> (which most TCP applications wouldn't care about),
> it is just not designed to replace Reno, C-TCP, CUBIC,
> H-TCP etc. You're comparing apples with oranges here.

I agree that MulTFRC is not a TCP variant, but it is a congestion
control algorithm.  I though it's aim was to be a rate-based companion
to MulTCP.

My argument is that MulTCP has not yet (to my knowledge) been assessed
by the ICCRG, but that the other congestion control algorithms that I
mentioned have.  If we are going to let a new rate-based congestion
control algorithm loose, we SHOULD (not MUST) choose one based on a
carefully-evaluated window-based algorithm in preference to a
less-well evaluated one.  That is, the draft should make a case why
rate-based "equivalents" of the approaches taken by CUBIC, C-TCP or
H-TCP are not suitable.

I wasn't suggesting that we use the window-based algorithms themselves
in DCCP.  I was suggesting that we do for them what you have done for
MulTCP**, and then compare all of the results by simulation/testbed
before taking the step of endorsing MulTFRC as experimental.

The logic behind TFRC was that the rate-based and window-based flows
should behave similarly in response to network conditions.  Given
that, we should make next-generation rate-based flows behave similarly
to next-generation window-based flows.  Why experiment with MulTFRC if
MulTCP isn't going to be deployed?

**That is, we should say "given this pattern of loss, what would the
window/RTT be?" and set the rate accordingly.

Note that these comments are just my opinions (and those of the
devil's advocate) to stimulate wider debate.  Everyone is welcome to
tear them to pieces, not just Michael.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] (Michael Welzl)
Date: Thu Jan 21 12:38:53 2010
Subject: [Iccrg] Answer to MulTFRC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Jan 21, 2010, at 1:05 AM, Lachlan Andrew wrote:

> Greetings Michael,
>
> 2010/1/20 Michael Welzl <[email-masked]>:
>> Concern #4:
>>
>> MulTFRC, like MulTCP, simply seems to increase (or decrease) the
>> aggressiveness, without regard for how large or small the BDP is.
>> Since TCP is (too?)aggressive on small-BDP paths, but not aggressive
>> enough on large-BDP paths, it is not clear that a "safe" setting  
>> of  N
>> will be useful.  I think even extremely aggressive algorithms are
>> unlikely to cause congestion collapse in the Internet, and so from
>> that point of view, MulTFRC is "safe".  However, if the
>> user/application can set  N,  then it could easily become part of the
>> "Linux beats Microsoft" arms race Michael described at PFLDnet.
>> (Lachlan)
>>
>> I would like to work out a solution for the small-BDP vs. large-BDP  
>> path
>> concern, but for this, I would need some more details about your
>> statement that "TCP is (too?) aggressive on small-BDP-paths".
>> Could you elaborate, maybe with a reference to a study showing
>> that TCP is too aggressive on small-BDP paths, and what exactly
>> you mean by "small"?
>
> My point was that standard TCP is   sufficiently   aggressive in a LAN
> environment.

Not necessarily - this depends on the buffer size:

> One example where standard TCP is too aggressive is in highly-buffered
> ADSL links.  (You could argue that the problem is the size of the
> buffer rather than the fact that the BDP is low, but if the BDP were
> higher then that size of buffer would be fine.)  The same is true of
> basically any loss-based algorithm, although Lawrence Stuart here at
> Swinburne showed that H-TCP's concave increase actually causes lower
> average queueing than Reno in these cases.

How do you define "too aggressive"?

It causes delay, by letting the queue overflow, which, as you
rightly say, is true for any loss-based algorithm. Having been
a part of it at Swinburne myself, I happen to know Lawrence's
investigation quite well  :-)

It led to some interesting and partially surprising conclusions,
but none that could be interpreted as "mechanism X is *too*
aggressive", because there was also no threshold set for
what "too" is supposed to mean. All loss-based mechanisms
can have a bad impact on VoIP, no doubt about that, and
some are worse than others.

I would argue that, while this is an interesting study, trying
to optimize a mechanism for it is to optimize it for a very
poorly tuned special circumstances, where the only real
solution is to throw all non-delay-based schemes away.

Indeed, the buffer size is the problem, and I don't see how
this fact changes by saying "if the BDP were higher then the
size of the buffer would be fine" - because it just isn't higher,
and if it was, the problem would disappear, both with
MulTFRC and with all other loss-based mechanisms.

>> About the arms race concern: one way to work against this
>> is to have a uniform system-wide non-user-accessible
>> upper limit, which we recommend to have.
>
> That limits the scalability.  It may buy us an extra generation of
> Ethernet (increase aggressiveness by a factor of 10 to match going
> from GbE to 10GbE), but doesn't address the inherent scalability
> problem.  We should be aiming to make changes now which can scale to
> bandwidths a million times higher than we currently have, like the
> original Tahoe/Reno algorithm did.

I don't get this, most probably it's a misunderstanding.
A limit of, e.g., N=6 emulated flows, will always give you
at least 95% link utilization or more, irrespective of the BDP.

>> One could argue that the value of this system-wide upper
>> limit could itself be a part of the arms race, no matter
>> what the specification recommends. However, we believe
>> this to be unlikely. As we state in the draft:
>> "Thus, setting N to a much larger value than the values
>> mentioned above will only yield a marginal benefit in
>> isolation but can significantly affect other traffic."
>
> That comment seems to apply only to current BDPs.  The setting of that
> upper limit is indeed the cause for concern.

Just like above, either you're misunderstanding what this
limit does or I'm misunderstanding your point.

>> Concern #5: "The abstract has a rather weak motivation and should
>> be strengthened"
>> (Dirceu)
>>
>> We'll do that.
>
> You can also think about why/whether this is the "right" solution for
> the need, as well as making a stronger case that there is a need.
>
> Of course, for an experimental RFC it need not be the very best
> solution, but receiving that stamp is a strong endorsement.  I'd be
> more in favour of a rate-based version of one of the new-generation
> algorithms already before the ICCRG (C-TCP, CUBIC or H-TCP) or LEDBAT.
> Once simulation/test-bed studies have shown which of the four options
> seems most promising for "new TFRC", we can set the best one loose on
> the internet.

Now that really makes no sense to me, as MulTFRC is
not a TCP variant, and by no means meant to be one.
Being slowly reactive, yet having a smooth sending rate
(which most TCP applications wouldn't care about),
it is just not designed to replace Reno, C-TCP, CUBIC,
H-TCP etc. You're comparing apples with oranges here.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Wed Jan 20 23:36:11 2010
Subject: [Iccrg] Answer to MulTFRC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

2010/1/20 Michael Welzl <[email-masked]>:
> Concern #4:
>
> MulTFRC, like MulTCP, simply seems to increase (or decrease) the
> aggressiveness, without regard for how large or small the BDP is.
> Since TCP is (too?)aggressive on small-BDP paths, but not aggressive
> enough on large-BDP paths, it is not clear that a "safe" setting of ?N
> will be useful. ?I think even extremely aggressive algorithms are
> unlikely to cause congestion collapse in the Internet, and so from
> that point of view, MulTFRC is "safe". ?However, if the
> user/application can set ?N, ?then it could easily become part of the
> "Linux beats Microsoft" arms race Michael described at PFLDnet.
> (Lachlan)
>
> I would like to work out a solution for the small-BDP vs. large-BDP path
> concern, but for this, I would need some more details about your
> statement that "TCP is (too?) aggressive on small-BDP-paths".
> Could you elaborate, maybe with a reference to a study showing
> that TCP is too aggressive on small-BDP paths, and what exactly
> you mean by "small"?

My point was that standard TCP is   sufficiently   aggressive in a LAN
environment.

One example where standard TCP is too aggressive is in highly-buffered
ADSL links.  (You could argue that the problem is the size of the
buffer rather than the fact that the BDP is low, but if the BDP were
higher then that size of buffer would be fine.)  The same is true of
basically any loss-based algorithm, although Lawrence Stuart here at
Swinburne showed that H-TCP's concave increase actually causes lower
average queueing than Reno in these cases.

> About the arms race concern: one way to work against this
> is to have a uniform system-wide non-user-accessible
> upper limit, which we recommend to have.

That limits the scalability.  It may buy us an extra generation of
Ethernet (increase aggressiveness by a factor of 10 to match going
from GbE to 10GbE), but doesn't address the inherent scalability
problem.  We should be aiming to make changes now which can scale to
bandwidths a million times higher than we currently have, like the
original Tahoe/Reno algorithm did.

> One could argue that the value of this system-wide upper
> limit could itself be a part of the arms race, no matter
> what the specification recommends. However, we believe
> this to be unlikely. As we state in the draft:
> "Thus, setting N to a much larger value than the values
> mentioned above will only yield a marginal benefit in
> isolation but can significantly affect other traffic."

That comment seems to apply only to current BDPs.  The setting of that
upper limit is indeed the cause for concern.

> Concern #5: "The abstract has a rather weak motivation and should
> be strengthened"
> (Dirceu)
>
> We'll do that.

You can also think about why/whether this is the "right" solution for
the need, as well as making a stronger case that there is a need.

Of course, for an experimental RFC it need not be the very best
solution, but receiving that stamp is a strong endorsement.  I'd be
more in favour of a rate-based version of one of the new-generation
algorithms already before the ICCRG (C-TCP, CUBIC or H-TCP) or LEDBAT.
 Once simulation/test-bed studies have shown which of the four options
seems most promising for "new TFRC", we can set the best one loose on
the internet.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] (Michael Welzl)
Date: Wed Jan 20 21:16:37 2010
Subject: [Iccrg] MulTFRC is now an RG document
Message-ID: <[email-masked]>

Dear all,

It has now been decided that our MulTFRC draft:
draft-welzl-multfrc-01.txt
will be a RG document of ICCRG, with the intention to publish
it as an Experimental RFC via this group.

A page with documentation and all relevant links is at:
http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_multfrc

These "relevant links" include the recent reviews, which have
absolutely not lost the slightest bit of their value by this shift!
In fact, they showed that there seems to be more interest
and/or expertise for MulTFRC here than in DCCP.

We (authors) will do our best to address the comments as good
and soon as we can. Thanks again to the reviewers!

Cheers,
Michael

From: [email-masked] (Dirceu Cavendish)
Date: Wed Jan 20 07:37:48 2010
Subject: [Iccrg] MulTFRC draft review
Message-ID: <[email-masked]>

Here is my quick review to Welzl's draft on MulTFRC.

The abstract of the draft has a rather weak motivation. I think the abstract should be strenghtened, so as to make a stronger case for the need of the draft. Is the motivation to provide a mechanism to tune the aggressiveness of TFRC?

New equation X_Bps: Some explanation so as to why or at least a pointer to a paper that describes the equation derivation and properties is in order.The pointer provided [Dam+08] presents the results, and points to a tech report for derivation.The important point, however, is to have an idea of the range of rates produced by the equation. The original TFRC equation is much easier to understand and make a "safety" analysis of Bps possible range values than the proposed new equation IMHO.

An implementation consideration session is also helpful to discuss issues such as how to work around the lack of floating point operations in Linux Kernel, for instance...

Dirceu

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100120/b3896880/attachment.html
>From [email-masked]  Wed Jan 20 12:55:22 2010
From: [email-masked] (Michael Welzl)
Date: Wed Jan 20 12:26:14 2010
Subject: [Iccrg] Answer to MulTFRC reviews
Message-ID: <[email-masked]>

Hi,

First of all, I would like to deeply thank the reviewers
for their efforts. It is extra cool that they all ended up
sending their comments at almost exactly the same
time, this makes things quite efficient  :-)

Since the comments overlap quite a bit, I'll try to answer
them all with a single email and hope that the review
authors agree that their concerns are amply represented
here.

Concern #1: "The equation doesn't look very intuitive / is quite  
complex"
(Wes, Dirceu)

This is very hard to address. The derivation is quite
straightforward, but the outcome just doesn't look
intuitive; we'll do our best to address this, e.g. by
providing some basic hints about how the derivation
works.

This is maybe connected to:

Concern #2: "The draft does not state which reference describes
the derivation"
(Lachlan, Dirceu)

This is easy to fix, and we'll do that (that reference is [Dam+08]).

Concern #3: "It will be hard to ensure that this is correctly
implemented, e.g. there may be issues with fixed-point math"
(Wes, Lachlan, Dirceu)

About implementation problems resulting from the complexity
of the equation, our suggestion is to provide more hints in
the draft - e.g. we could add a table with input / output values
that correct implementations should yield, for easier testing.

About the fixed-point math issue, Dirceu mentioned "how to
work around the lack of floating point operations in Linux Kernel,
for instance", and Lachlan provided more details about the
equation calculation, saying that some operations ideally cancel
each other out but "may cause overflow when implemented in
fixed-point arithmetic, as done in kernels".

We believe that this concern is very valid, but the problem
surely can be solved. We will develop an explanation on
how to implement the equation with fixed-point arithmetic,
making use of the helpful hints provided by Lachlan (e.g.
we'll reconsider the sequence of operations).

Concern #4:

MulTFRC, like MulTCP, simply seems to increase (or decrease) the
aggressiveness, without regard for how large or small the BDP is.
Since TCP is (too?)aggressive on small-BDP paths, but not aggressive
enough on large-BDP paths, it is not clear that a "safe" setting of  N
will be useful.  I think even extremely aggressive algorithms are
unlikely to cause congestion collapse in the Internet, and so from
that point of view, MulTFRC is "safe".  However, if the
user/application can set  N,  then it could easily become part of the
"Linux beats Microsoft" arms race Michael described at PFLDnet.
(Lachlan)

I would like to work out a solution for the small-BDP vs. large-BDP path
concern, but for this, I would need some more details about your
statement that "TCP is (too?) aggressive on small-BDP-paths".
Could you elaborate, maybe with a reference to a study showing
that TCP is too aggressive on small-BDP paths, and what exactly
you mean by "small"?

About the arms race concern: one way to work against this
is to have a uniform system-wide non-user-accessible
upper limit, which we recommend to have.

One could argue that the value of this system-wide upper
limit could itself be a part of the arms race, no matter
what the specification recommends. However, we believe
this to be unlikely. As we state in the draft:
"Thus, setting N to a much larger value than the values
mentioned above will only yield a marginal benefit in
isolation but can significantly affect other traffic."

Concern #5: "The abstract has a rather weak motivation and should
be strengthened"
(Dirceu)

We'll do that.

Concern #6: "it's important to get an idea of the range of
rates produced by the equation"
(Dirceu)

We'll address that.

A big thanks again to all 3 of you!

Any comments are more than welcome. At this point, my
major concern is whether there is enough interest - so, for
those of you subscribed to the DCCP list, raise your voice
there, let us know whether you think if MulTFRC should
be a WG item or not. Thanks!

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Wed Jan 20 01:33:00 2010
Subject: [Iccrg] evaluation of MulTFRC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

2010/1/20 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
<[email-masked]>:
> In response to the interest in possibly specifying MulTFRC
> as a mechanism for DCCP, and the call for reviews in the
> ICCRG, I've looked at the available material.
>
> This is my personal review, and not an ICCRG consensus. ?I
> know at least Lachlan has also been looking at this, and
> may have come to a different conclusion.

Thanks, Wes.  My review (also my opinions, not ICCRG consensus) is below.

My technical concerns with MulTFRC are:

- The formula for the rate is quite complex.  This makes it likely for
implementation errors.  It also makes it hard to check for complete
safety.  This is especially so since the draft does not specify which
reference describes the derivation.

- The formula has many operations which ideally cancel each other out,
but may cause overflow when implemented in fixed-point arithmetic, as
done in kernels.  In particular, in congestions,  1-p  may be small,
and so having it in the denominator of  z  is likely to cause
overflow.  Since  z  is then multiplied by  (1-p)  anyway, it seems
sensible to do the division instead in the second re-calculation of
q.  At the very least, there should be some discussion of how the
specified sequence of operations is more robust to overflow than
alternatives.

- MulTFRC, like MulTCP, simply seems to increase (or decrease) the
aggressiveness, without regard for how large or small the BDP is.
Since TCP is (too?)aggressive on small-BDP paths, but not aggressive
enough on large-BDP paths, it is not clear that a "safe" setting of  N
 will be useful.  I think even extremely aggressive algorithms are
unlikely to cause congestion collapse in the Internet, and so from
that point of view, MulTFRC is "safe".  However, if the
user/application can set  N,  then it could easily become part of the
"Linux beats Microsoft" arms race Michael described at PFLDnet.

To clarify the point Wes mentioned about rate based vs window based, I
don't think that rate based algorithms inherently cause more problems.
 However, in my limited experience, they are more susceptible to
errors in assumptions about the network, and so we need to be
particularly careful.

However, if the second point above is eventually addressed, I think
that the algorithm is sufficiently "safe" than the DCCP wg can go
ahead and assess it on its merits as a congestion control algorithm.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] (Pasi Sarolahti)
Date: Wed Jan 20 00:42:25 2010
Subject: [Iccrg] Re: [dccp] evaluation of MulTFRC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, Wes, for the good review! This was very helpful.

- Pasi

On Jan 19, 2010, at 12:02 PM, Eddy, Wesley M. (GRC-MS00)[ASRC  
AEROSPACE CORP] wrote:

> In response to the interest in possibly specifying MulTFRC
> as a mechanism for DCCP, and the call for reviews in the
> ICCRG, I've looked at the available material.
>
> This is my personal review, and not an ICCRG consensus.  I
> know at least Lachlan has also been looking at this, and
> may have come to a different conclusion.
>
> I think there's no reason to block this if there's momentum
> to do the work in DCCP.  While there are definitely some
> concerns with the goal and approach, it seems to me that
> they aren't likely to cause any serious damage to the Internet.
> It's certainly not as dangerous as things people have done in
> the past, which the Internet survived :).
>
> That's the executive summary, some more detailed listing
> of thoughts is below.  Chatting with Lachlan helped to
> formulate some of these positions of mine (in response
> to points he made), but I think he should probably post
> his own thoughts separately as he may not agree with my
> overall feelings.
>
> One concern is that this is equation-based rather than
> window-based, and thus will not back-off as quickly as TCP
> under loss.  However, if it works correctly, then it will
> respond as TFRC flows do, and TFRC has been around for a
> while without disaster, so this doesn't really worry me.
>
> A related concern that came to light when I was discussing
> this with Lachlan is that there may be difficulties with
> fixed-point math in implementation, leading to errors or
> border cases that may be hard to ferret out in testing.
> This is probably a concern that applies to many/most advanced
> congestion control techniques, however, so I don't see it
> as a reason to throw a "danger" flag, personally.  The
> issues around this may be one thing we can learn more about
> as a community from pursuing this.
>
> Another concern is that the equations involved with MulTFRC
> and their derivation, seem much more complex than for TFRC.
> Granted, I'm not a mathematician, but TFRC equations are
> at least somewhat intuitive, whereas MulTFRC doesn't seem
> to be as easily comprehensible to me, even though the
> basic premise is simple.  However, I think that it's
> been reasonably-well documented and validated in the TR:
> http://heim.ifi.uio.no/michawe/research/publications/dragana_tech_rep.pdf
> and that the most productive way to discover if there are
> any flaws is to pursue further work, such as in DCCP.
>
> Overall, while I think there's probably a high risk of
> something being "not quite right" in an implementation,
> I also think the impact of that upon the Internet will
> be negligible.  A major factor in this is that for it
> to cause trouble would likely require fairly wide
> penetration of DCCP and conscious application choice to
> use MulTFRC ... Yes, this could happen overnight in
> "Internet time" with the way that code is deployed to
> desktops these days.  But, even if this happened AND
> something went horribly wrong, we would at least gain
> some cultural knowledge of how careful we really need
> to be (or not) with either equation-based mechanisms
> or mechanisms with complex derivations, and whether
> bugs are derived from implementation or specification.
>
> For reference, the original solicitation for review is:
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2009-November/000716.html
> which also has pointers to some of the primary material.
>
> --
> Wes Eddy
> MTI Systems
>
>

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Tue Jan 19 19:33:07 2010
Subject: [Iccrg] evaluation of MulTFRC
Message-ID: <[email-masked]>

In response to the interest in possibly specifying MulTFRC
as a mechanism for DCCP, and the call for reviews in the
ICCRG, I've looked at the available material.

This is my personal review, and not an ICCRG consensus.  I
know at least Lachlan has also been looking at this, and
may have come to a different conclusion.

I think there's no reason to block this if there's momentum
to do the work in DCCP.  While there are definitely some
concerns with the goal and approach, it seems to me that
they aren't likely to cause any serious damage to the Internet.
It's certainly not as dangerous as things people have done in
the past, which the Internet survived :).

That's the executive summary, some more detailed listing
of thoughts is below.  Chatting with Lachlan helped to
formulate some of these positions of mine (in response
to points he made), but I think he should probably post
his own thoughts separately as he may not agree with my
overall feelings.

One concern is that this is equation-based rather than
window-based, and thus will not back-off as quickly as TCP
under loss.  However, if it works correctly, then it will
respond as TFRC flows do, and TFRC has been around for a
while without disaster, so this doesn't really worry me.

A related concern that came to light when I was discussing
this with Lachlan is that there may be difficulties with
fixed-point math in implementation, leading to errors or
border cases that may be hard to ferret out in testing.
This is probably a concern that applies to many/most advanced
congestion control techniques, however, so I don't see it
as a reason to throw a "danger" flag, personally.  The
issues around this may be one thing we can learn more about
as a community from pursuing this.

Another concern is that the equations involved with MulTFRC
and their derivation, seem much more complex than for TFRC.
Granted, I'm not a mathematician, but TFRC equations are
at least somewhat intuitive, whereas MulTFRC doesn't seem
to be as easily comprehensible to me, even though the
basic premise is simple.  However, I think that it's
been reasonably-well documented and validated in the TR:
http://heim.ifi.uio.no/michawe/research/publications/dragana_tech_rep.pdf
and that the most productive way to discover if there are
any flaws is to pursue further work, such as in DCCP.

Overall, while I think there's probably a high risk of
something being "not quite right" in an implementation,
I also think the impact of that upon the Internet will
be negligible.  A major factor in this is that for it
to cause trouble would likely require fairly wide
penetration of DCCP and conscious application choice to
use MulTFRC ... Yes, this could happen overnight in
"Internet time" with the way that code is deployed to
desktops these days.  But, even if this happened AND
something went horribly wrong, we would at least gain
some cultural knowledge of how careful we really need
to be (or not) with either equation-based mechanisms
or mechanisms with complex derivations, and whether
bugs are derived from implementation or specification.

For reference, the original solicitation for review is:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2009-November/000716.html
which also has pointers to some of the primary material.

--
Wes Eddy
MTI Systems

From: [email-masked] ([email-masked])
Date: Fri Jan  8 04:20:42 2010
Subject: [Iccrg] {SPAM?} BBVA te premio con 100 euros .
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100108/b0724511/attachment.html
>From [email-masked]  Mon Jan 18 19:08:51 2010
From: [email-masked] (Eddy,
	Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Mon Jan 18 18:40:34 2010
Subject: [Iccrg] presentation evaluating proposed congestion control
	algorithms
Message-ID: <[email-masked]>

Kevin had some trouble posting this to the ICCRG list, so I'm
sending it for him.  We're soliciting feedback on whether people
would like to have a little bit longer session at the Anaheim
IETF meeting for Kevin to present this work to the ICCRG there,
or whether a shorter summary would suffice.  Of course, the
mailing list is also open to comment on and discuss this
material, as we have a bit in the past.

--
Wes Eddy
MTI Systems

-----Original Message-----
From: Mills, Kevin L. 
Sent: Monday, January 11, 2010 2:23 PM
To: [email-masked]'
Subject: A Presentation is Available Entitled: "Study of Proposed Internet Congestion Control Algorithms"

You are welcome to download the subject presentation from http://www.nist.gov/itl/antd/upload/GMUpresentation-1292012.pdf 

If you have comments, then let me know.

If you are interested in discussing this study at a future ICCRG meeting, then please let Wes and Michael know.

Thanks,

Kevin Mills

NIST
100 Bureau Drive Stop 8920
Bldg. 222/B218
Gaithersburg, MD 20899-8920

Tel: (301) 975-3618
Fax: (301) 975-6238
email: [email-masked]
web: http://w3.antd.nist.gov/~mills

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Wed Jan  6 16:34:59 2010
Subject: [Iccrg] next meeting @ IETF 77 in Anaheim, March 21-26
Message-ID: <[email-masked]>

We've requested a meeting room at the upcoming IETF 77
meeting in Anaheim for the ICCRG to have a meeting,
which will be between March 21-26:
http://www.ietf.org/meeting/77/index.html

If there are things you'd like to talk about, please
let Michael and I know as we begin to form an agenda.

--
Wes Eddy
MTI Systems