Subject: [Iccrg] CFP: Computer Networks Journal Special Issue: Architectures and Protocols for the Future Internet
From: [email-masked] (Lars Eggert)
Date: Wed Feb 24 10:24:24 2010

Call for Papers

Computer Networks Journal ? Special Issue
Architectures and Protocols for the Future Internet

The Internet architecture has been remarkably successful in allowing a
planet-scale internetwork to form. However, the architecture has been
losing its original simplicity and transparency as new classes of
applications, business models, security mechanisms, scalability enablers
and operational and management requirements have given rise to point
solutions that extend the architecture without regard to its original
design principles.

Consequently, the research community has been actively looking for new
approaches to evolve or supersede the Internet architecture. Substantial
academic efforts in Europe, the Americas and Asia, as well as within the
vendor and network operator communities have resulted in promising
proposals to address the limitations of the current Internet
architecture.

This special issue of the Computer Networks Journal solicits original,
high-quality papers that present, analyze and discuss revolutionary
"clean slate" or evolutionary "dirty slate" Internet architectures,
"future-proofing" improvements to current Internet protocols, especially
at the internetworking, routing, transport and application layers, or
new internetworking components that integrate into the existing
architecture. Related topics, such as measurement studies or
mathematical models that analyze and quantify Internet scalability
issues, studies into architectural design principles that enable
evolution, interworking technologies with the existing Internet, and
others are also within the scope of the special issue.

About the Computer Networks Journal

Computer Networks is a scientific journal of computer and
telecommunications networking published by Elsevier. Computer Networks
is an international, archival journal providing a publication vehicle
for complete coverage of all topics of interest to those involved in the
computer communications networking area. The audience includes
researchers, managers and operators of networks as well as designers and
implementors.

Submission Format

Submissions should be clearly organized, written in excellent English
and must describe original, complete research not published or currently
under review by other journals or conferences. Substantially enhanced
and extended versions of quality papers presented at conferences or
workshops may be submitted with the differences to the previous version
clearly described.

All submissions will be peer reviewed. The guest editors reserve the
right to reject submissions that are clearly out of scope or well below
the expected quality for this special journal issue without further
review.

Submission Guidelines

Authors must prepare and format their submissions according to the
"Guide for Authors" available from http://ees.elsevier.com/comnet/ and
submit them online at the same URL, choosing "SI-Future Internet" as the
article type.

Submissions must be in single-column format, double-spaced, use a font
size of at least 11 points, and should not exceed 25 pages including all
figures and references.

Guest Editors

      Lars Eggert
      Nokia Research Center & Aalto University
      [email-masked] 

      Tilman Wolf
      University of Massachusetts
      [email-masked]

Editors in Chief

      Ian F. Akyildiz
      [email-masked]

      Harry Rudin
      [email-masked]

Important Dates

Paper submission:               2010-4-30
Acceptance notification:        2010-7-16
Final papers:                   2010-8-27
Publication:                    early 2011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2490 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100224/110e70da/smime.bin
>From [email-masked]  Fri Feb 26 20:10:40 2010
From: [email-masked] ([email-masked])
Date: Fri Feb 26 22:05:17 2010
Subject: [Iccrg] =?iso-8859-1?q?=7BSPAM=3F=7D_Promo_=E3o_Nestl_em_Ritmo_d?=
	=?iso-8859-1?q?e_Pr_mios?=
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100226/d054974d/attachment.html

From: [email-masked] (grenville armitage)
Date: Tue Feb 23 21:23:19 2010
Subject: [Iccrg] Re: Software for FreeBSD TCP R&D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 24/02/2010 6:02 AM, Patrick Mahan wrote:
>> [12] http://caia.swin.edu.au/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch
>>
>> [13] http://caia.swin.edu.au/newtcp/tools/modularcc-readme-0.9.4.txt
>>
> 
> I believe these are incorrect.  I find these documents at the following URLs:
> 
> [12] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch
> [13] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.9.4.txt

Good catch. Very embarrassing. Since the URLs are now stored in a bunch of
mailing list archives, I've linked http://caia.swin.edu.au/newtcp/ to
http://caia.swin.edu.au/urp/newtcp/ to make the wrong URLs work.

cheers,
gja

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Mon Feb 22 22:19:52 2010
Subject: [Iccrg] IETF 77 agenda planning
Message-ID: <[email-masked]>

On the *draft* agenda for IETF 77, ICCRG has two meeting slots:
https://datatracker.ietf.org/meeting/77/agenda.html

We are working on developing the ICCRG agenda(s), and at the
moment have several requests for time.  If there are any more
people that would like to present which I don't know about,
please let Michael and I know, as it may be a pretty full
agenda.

The draft agenda so far is:

First Session (2.5 hours)
=======================

Title: RG Status
Presenter: Chairs
Time: 5 minutes

Title: "around the IETF" - short overview of work going
       on in IETF WGs related to CC and how it relates
       to ICCRG "open issues"
Presenter: Chairs
Time: 10 minutes

Title: Internet Capacity Sharing Architecture
Presenter: Bob Briscoe / Matt Mathis (TBD)
Time: 45 minutes

Title: Increasing the Initial CWND
Presenter: Jerry Chu
Time: 45 minutes
(related to work possibly discussed in TCPM)

Title: Reducing the Initial RTO
Presenter: Jerry Chu
Time: 5 minutes
(overview for ICCRG awareness, but main work to-be discussed in TCPM)

Title: Placeholder (TBD)
Presenter: Lachlan Andrew
Time: TBD (bookmark 10 minutes)

Title: Placeholder (TBD)
Presenter: Matt Mathis
Time: TBD (bookmark 10 minutes)

Title: Congestion Definition
Presenter: John Leslie
Time: extend until end of session (may spill to 2nd session)

Second Session (1 hour)
=======================

Title: Study of Proposed Internet Congestion Control Protocols
Presenter: Kevin Mills
Time: bookmark full session time

--
Wes Eddy
MTI Systems

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Mon Feb 22 21:55:07 2010
Subject: FW: [Iccrg] presentation evaluating proposed congestion  controlalgorithms
Message-ID: <[email-masked]>

(forwarded with permission)

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: Narasimha Reddy [mailto:[email-masked]]
>Sent: Monday, January 18, 2010 3:42 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; [email-masked]
>Subject: RE: [Iccrg] presentation evaluating proposed congestion
>controlalgorithms
>
>Kevin, can you please include PERT in your next round of evaluations?
>
>You can find pointers to PERT here:
>
>http://www.ece.tamu.edu/~reddy/papers/sigcomm07.pdf
>
>http://www.ece.tamu.edu/~reddy/papers/iwqos2008.pdf
>
>Our evaluation found some interesting insights. You may want to look at
>my student's thesis at
>http://cegroup.ece.tamu.edu/techpubs/2008/TAMU-ECE-2008-02.pdf
>
>where we compare FAST, PERT competing against TCP.
>
>I will be happy to provide necessary ns-2 code for PERT.
>
>Your evaluation is quite interesting and thorough.
>
>Reddy
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Eddy,Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>Sent: Monday, January 18, 2010 1:09 PM
>To: [email-masked]
>Subject: [Iccrg] presentation evaluating proposed congestion
>controlalgorithms
>
>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
>
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Matt Mathis)
Date: Mon Feb 22 03:01:42 2010
Subject: [Iccrg] Fwd: agenda planning for ICCRG in Anaheim
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, Feb 21, 2010 at 6:08 PM, Lachlan Andrew
<[email-masked]> wrote:
> Greetings Michael
>
> On 22 February 2010 09:07, Michael Welzl <[email-masked]> wrote:
>> On Feb 21, 2010, at 10:48 PM, Matt Mathis wrote:
>>>
>>> Therefor: all stacks should include a secondary congestion control
>>> mechanism that detects the delay caused by large queues in the network
>>> and regulates their congestion window accordingly.
>>
>>> It may be an appropriate future work item of the ICCRG and IETF to
>>> attempt to standardize such a mechanism. ? In the short term it would
>>> be sufficient to merely agree on a statement of principle or intent.
>>
>> - attempting to standardize: isn't that exactly what LEDBAT is doing?
>
> I thought LEDBAT was specifically for less-than-best-effort. ?Matt's
> proposal is that *all* stacks should consider delay. ?That is, we also
> want a replacement which is competitive with standard TCP "on
> average", although perhaps less aggressive when buffers are large and
> more aggressive either in the presence of non-congestion loss or when
> recovering from transient congestion.

Even simpler: use the same basic algorithm as LEDBAT, except use a set
point that is double the baseline delay plus a small constant.   This
basically stops the queue from getting too much larger than necessary
to maintain full link rate following any background random loss.

My home ISP has 5 full seconds of queuing on the outbound side.  Given
that standard TCP controls against a full drop-tail queue and modern
stacks autotune out to a couple of megabyte windows, simply
downloading a large file makes the link absolutely unusable for
anything else.   Although one could argue that the real problem is
with the ISP, there is simply no reason for TCP to create a standing
queue that is 50 times larger than the baseline delay.

I didn't realize the potential scale of the impending trainwreck,
until one of my adult children commented about how his nice new
computer completely trampled everything else on his home LAN.    He
asked if I had any idea why.....

I think we have only seen the tip of the iceberg.

Thanks,
--MM--

From: [email-masked] (Michael Welzl)
Date: Sun Feb 21 23:31:45 2010
Subject: [Iccrg] Fwd: agenda planning for ICCRG in Anaheim
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Feb 22, 2010, at 12:08 AM, Lachlan Andrew wrote:

> Greetings Michael
>
> On 22 February 2010 09:07, Michael Welzl <[email-masked]> wrote:
>> On Feb 21, 2010, at 10:48 PM, Matt Mathis wrote:
>>>
>>> Therefor: all stacks should include a secondary congestion control
>>> mechanism that detects the delay caused by large queues in the  
>>> network
>>> and regulates their congestion window accordingly.
>>
>>> It may be an appropriate future work item of the ICCRG and IETF to
>>> attempt to standardize such a mechanism.   In the short term it  
>>> would
>>> be sufficient to merely agree on a statement of principle or intent.
>>
>> - attempting to standardize: isn't that exactly what LEDBAT is doing?
>
> I thought LEDBAT was specifically for less-than-best-effort.  Matt's
> proposal is that *all* stacks should consider delay.  That is, we also
> want a replacement which is competitive with standard TCP "on
> average", although perhaps less aggressive when buffers are large and
> more aggressive either in the presence of non-congestion loss or when
> recovering from transient congestion.

I just said that LEDBAT is attempting to standardize a mechanism
that does such a thing (no matter what its focus is). I didn't interpret
Matt's statement to mean that we also want a replacement which is
"on average" competitive with standard TCP, but such a mechanism
is surely an interesting consideration.

> CTCP fits the final part of that (recovering faster from transient
> congestion), but misses the other components.
>
> Also, since LEDBAT is IETF not IRTF, it is not doing research.  It
> will standardise something, but probably not the best thing.  The
> ICCRG can take a longer term view, and hopefully get it right before
> putting a proposal to the IETF.

Agree 100%, and I like the requirements you lay out above
for a delay-based mechanism. I find it a bit hard to imagine
what such a mechanism could look like, though, but where
there's a will, there's a way, they say...

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Sun Feb 21 23:21:22 2010
Subject: [Iccrg] Fwd: agenda planning for ICCRG in Anaheim
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael

On 22 February 2010 09:07, Michael Welzl <[email-masked]> wrote:
> On Feb 21, 2010, at 10:48 PM, Matt Mathis wrote:
>>
>> Therefor: all stacks should include a secondary congestion control
>> mechanism that detects the delay caused by large queues in the network
>> and regulates their congestion window accordingly.
>
>> It may be an appropriate future work item of the ICCRG and IETF to
>> attempt to standardize such a mechanism. ? In the short term it would
>> be sufficient to merely agree on a statement of principle or intent.
>
> - attempting to standardize: isn't that exactly what LEDBAT is doing?

I thought LEDBAT was specifically for less-than-best-effort.  Matt's
proposal is that *all* stacks should consider delay.  That is, we also
want a replacement which is competitive with standard TCP "on
average", although perhaps less aggressive when buffers are large and
more aggressive either in the presence of non-congestion loss or when
recovering from transient congestion.

CTCP fits the final part of that (recovering faster from transient
congestion), but misses the other components.

Also, since LEDBAT is IETF not IRTF, it is not doing research.  It
will standardise something, but probably not the best thing.  The
ICCRG can take a longer term view, and hopefully get it right before
putting a proposal to the IETF.

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: Sun Feb 21 23:00:39 2010
Subject: [Iccrg] Delay as a metric of congestion
In-Reply-To: <20100221221258.GB2694@verdi>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]> <20100221221258.GB2694@verdi>
Message-ID: <[email-masked]>

On Feb 21, 2010, at 11:12 PM, John Leslie wrote:

> Matt Mathis <[email-masked]> wrote:
>>
>> John and I went around on this for a bit in a private conversation,
>> where I argued against his position.
>
>   I'm not positive what Matt "argued against," but it certainly wasn't
> my "position"...

although I did agree with what Matt wrote, it seems that
you really have a common base there:

>
>> Therefor: all stacks should include a secondary congestion control
>> mechanism that detects when they are causing large queues in the  
>> network
>> and regulates their congestion window accordingly.
>
>   I couldn't agree with that exact wording, but Matt & I may be close
> here. Perhaps:
> "
> " Stacks intending to "play nice" with TCP should implement a delay- 
> based
> " mechanism to avoid reaching a congestion level where packets they  
> send
> " are dropped instead of delivered. Research into such methods is an
> " appropriate field of study of the ICCRG.

... also in that I think my answer also applies to your statement,
I think: isn't that what LEDBAT is doing?

Okay, "research into such methods" is not exactly what LEDBAT
does, but it seems to me that the right way to start such research
would be an overview of current literature. There would be
quite a bit of overlap between such a literature overview and
what I'm writing (now together with David Ros) for LEDBAT.
We're going to submit the first "draft-ietf-ledbat.." version soon;
the previous version is:
http://tools.ietf.org/html/draft-welzl-ledbat-survey-00

I think that the very mechanism proposed in LEDBAT:
http://www.ietf.org/id/draft-ietf-ledbat-congestion-00.txt
might be a good candidate for what you propose above.

Cheers,
Michael

From: [email-masked] (John Leslie)
Date: Sun Feb 21 22:25:52 2010
Subject: [Iccrg] Delay as a metric of congestion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]>
Message-ID: <20100221221258.GB2694@verdi>

Matt Mathis <[email-masked]> wrote:
> 
> John and I went around on this for a bit in a private conversation,
> where I argued against his position.

   I'm not positive what Matt "argued against," but it certainly wasn't
my "position"...

> However, Wes's comments about the history made me realize that I
> actually very strongly agree with a slightly weaker, conditional
> version of John's position.
> 
> Given that:
> 
> 1) When delay sensing works it generally provides better, more precise, 
> congestion control with less disruption to other applications than loss 
> based congestion control.

   I did not take that position, but I won't argue against it...

> 2) Delay sensing does not work in all environments and must be considered 
> to be an optimization that is conditionally applied in addition to the 
> primary loss based congestion control.

   I don't even agree with that...

> 3) For the vast majority of Internet users (e.g. home users behind a slow, 
> over buffered access link and perhaps wireless users) #1 applies extremely 
> strongly.

   I think Matt means that if we can determine that the bottleneck is
between the end-user and his/her ISP, delay is a better metric. I would
agree with that.
`
> Therefor: all stacks should include a secondary congestion control 
> mechanism that detects when they are causing large queues in the network 
> and regulates their congestion window accordingly.

   I couldn't agree with that exact wording, but Matt & I may be close
here. Perhaps:
" 
" Stacks intending to "play nice" with TCP should implement a delay-based
" mechanism to avoid reaching a congestion level where packets they send
" are dropped instead of delivered. Research into such methods is an
" appropriate field of study of the ICCRG.

> It may be an appropriate future work item of the ICCRG and IETF to
> attempt to standardize such a mechanism.

  I think in appropriate _now_ to collect data on how well delay-based
reductions (not necessarily multiplicative reductions) in window size
signal "gzornenplat" and avoid packets being dropped.

   ("gzornenplat" is a placeholder for what I actually wanted to talk
about: the onset of what I call "congestion", but not so much of it as
to require packets to be dropped.)

> In the short term it would be sufficient to merely agree on a statement
> of principle or intent.

   I really don't see how that would help...

   (Nor did I intend to talk of anything like this in my proposed
presentation...)

--
John Leslie <[email-masked]>

From: [email-masked] (Michael Welzl)
Date: Sun Feb 21 22:20:43 2010
Subject: [Iccrg] Fwd: agenda planning for ICCRG in Anaheim
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

(chair hat off)

On Feb 21, 2010, at 10:48 PM, Matt Mathis wrote:

> John and I went around on this for a bit in a private conversation,
> where I argued against some of the details of his position.  However,
> Wes's comments about the history made me realize that I actually very
> strongly agree with a slightly weaker, conditional version of "delay
> indicates congestion".
>
> Given that:
>
> 1) When delay sensing works, it generally provides better, more
> precise, congestion control with less disruption to other applications
> than does loss based congestion control.
>
> 2) Delay sensing does not work in all environments and must be
> considered to be an optimization that is conditionally applied in
> addition to loss based congestion control.
>
> 3) For the vast majority of Internet users (e.g. home users behind
> slow, over buffered access links and perhaps wireless users) #1
> applies extremely strongly.
>
> Therefor: all stacks should include a secondary congestion control
> mechanism that detects the delay caused by large queues in the network
> and regulates their congestion window accordingly.

I strongly agree with this;

> It may be an appropriate future work item of the ICCRG and IETF to
> attempt to standardize such a mechanism.   In the short term it would
> be sufficient to merely agree on a statement of principle or intent.

- attempting to standardize: isn't that exactly what LEDBAT is doing?

Cheers,
Michael

From: [email-masked] (Matt Mathis)
Date: Sun Feb 21 22:00:59 2010
Subject: [Iccrg] Fwd: agenda planning for ICCRG in Anaheim
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20100220131348.GD5717@verdi> <[email-masked]> <20100220153516.GH5717@verdi> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

John and I went around on this for a bit in a private conversation,
where I argued against some of the details of his position. ?However,
Wes's comments about the history made me realize that I actually very
strongly agree with a slightly weaker, conditional version of "delay
indicates congestion".

Given that:

1) When delay sensing works, it generally provides better, more
precise, congestion control with less disruption to other applications
than does loss based congestion control.

2) Delay sensing does not work in all environments and must be
considered to be an optimization that is conditionally applied in
addition to loss based congestion control.

3) For the vast majority of Internet users (e.g. home users behind
slow, over buffered access links and perhaps wireless users) #1
applies extremely strongly.

Therefor: all stacks should include a secondary congestion control
mechanism that detects the delay caused by large queues in the network
and regulates their congestion window accordingly.

It may be an appropriate future work item of the ICCRG and IETF to
attempt to standardize such a mechanism. ? In the short term it would
be sufficient to merely agree on a statement of principle or intent.

Thanks,
--MM--
-------------------------------------------
Matt Mathis ? ? http://staff.psc.edu/mathis
Work:412.268.3319 ? ?Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

From: [email-masked] ([email-masked])
Date: Fri Feb 12 04:38:02 2010
Subject: [Iccrg] {SPAM?} Recadastre seus dados
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100212/698f6402/attachment.html
>From [email-masked]  Fri Feb 19 06:17:25 2010
From: [email-masked] (David Hayes)
Date: Fri Feb 19 06:31:34 2010
Subject: [Iccrg] Software for FreeBSD TCP R&D
Message-ID: <[email-masked]>

Hi All,

We're pleased to announce the release of a substantial set of new
and updated software for TCP research using FreeBSD:

 - Hamilton Delay Congestion Control Algorithm v0.1 (new)
 - Vegas Congestion Control Algorithm v0.1 (new)
 - ERTT Khelp Module v0.1 (new)
 - Khelp Framework for FreeBSD v0.1.0 (new)
 - Modular TCP Congestion Control for FreeBSD v0.9.4 (update)

Everything is available from [1] as BSD licenced source, along
with other papers, patches and software relevant/useful for
protocol analysis, debugging and experimental research.

Hamilton Delay Congestion Control Algorithm v0.1 [2,3]
------------------------------------------------
A FreeBSD loadable kernel module that implements an experimental
delay based congestion control algorithm proposed by the Hamilton
Institute [4]. It provides a first step toward the ability of
delay based algorithms to fairly coexist with loss based
algorithms.

Vegas Congestion Control Algorithm v0.1 [5,6]
--------------------------------------
A FreeBSD loadable kernel module that implements the VEGAS
congestion control algorithm [7].

ERTT Khelp Module v0.1 [8,9]
----------------------
A FreeBSD loadable kernel module that provides Enhanced Round
Trip Time (ERTT) measurements for use by delay and rate based TCP
congestion control algorithms. Robust estimates of RTT are
provided even when the receiver uses delayed acknowledgements,
TCP segmentation offload (TSO) or Selective Acknowledgements
(SACK). This module is required by the delay based congestion
control algorithms.

Khelp Framework for FreeBSD v0.1.0 [10,11]
----------------------------------
A FreeBSD kernel patch that provides support for generic kernel
modules known as "helpers" to hook into arbitrary points within
the kernel and provide service(s) to the running system. This
forms the foundation for the ERTT Khelp module.

Modular TCP Congestion Control for FreeBSD v0.9.4 [12,13]
-------------------------------------------------
This revision of the Modular TCP Congestion control framework
patch provides a current snapshot of the project's subversion
branch, with numerous tweaks, bug fixes and enhancements to
support the new delay based congestion control algorithms we have
been working on.

This software was developed as part of the NewTCP research
project at Swinburne University's Centre for Advanced Internet
Architectures, made possible in part by a grant from the Cisco
University Research Program Fund at Community Foundation Silicon
Valley. Testing and development was further assisted by a grant
from the FreeBSD Foundation.

We welcome any feedback and hope you enjoy playing with the code
and tools.

Cheers,
David Hayes, Lawrence Stewart and Grenville Armitage

http://caia.swin.edu.au

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

[2] http://caia.swin.edu.au/newtcp/tools/cc_hd-0.1.tar.gz

[3] http://caia.swin.edu.au/newtcp/tools/cc_hd-readme-0.1.txt

[4] L. Budzisz, R. Stanojevic, R. Shorten, and F. Baker, "A
strategy for fair coexistence of loss and delay-based congestion
control algorithms", IEEE Commun. Lett., vol. 13, no. 7,
pp. 555-557, Jul. 2009.

[5] http://caia.swin.edu.au/newtcp/tools/cc_vegas-0.1.tar.gz

[6] http://caia.swin.edu.au/newtcp/tools/cc_vegas-readme-0.1.txt

[7] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end
congestion avoidance on a global internet", IEEE J. Sel. Areas
Commun., vol. 13, no. 8, pp. 1465-1480, Oct. 1995.

[8] http://caia.swin.edu.au/newtcp/tools/h_ertt-0.1.tar.gz

[9] http://caia.swin.edu.au/newtcp/tools/h_ertt-readme-0.1.txt

[10]
http://caia.swin.edu.au/newtcp/tools/caia_khelp_framework_v0.1.0_9.x.r203910.patch

[11] http://caia.swin.edu.au/newtcp/tools/khelp-readme-0.1.0.txt

[12]
http://caia.swin.edu.au/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch

[13]
http://caia.swin.edu.au/newtcp/tools/modularcc-readme-0.9.4.txt

-- 
David Hayes
Research Fellow
Centre for Advanced Internet Architectures
Faculty of Information and Communication Technologies
Swinburne University of Technology, Australia
http://caia.swin.edu.au/cv/dahayes/