Subject: [Iccrg] open-issues rfc
From: [email-masked] (Wesley Eddy)
Date: Thu Mar 29 20:22:40 2007

At the ICCRG meeting in February, there was some deal of discussion on
open issues in the field of congestion control.  The group identified
several, including (at least):

1) high-rate schemes
2) detection and proper treatment of corruption loss
3) media-flows, including small packet flows
4) router support (implicit / explicit feedback, etc.)
5) pseudowires
6) pre-congestion notification
7) precedence for elastic traffic
8) misbehaving senders and receivers
9) maybe more ...

Michael has a slide at the very end of his presentation that lists the
ones that came out in the meeting:
http://www1.tools.ietf.org/group/irtf/trac/attachment/wiki/Agenda/michael_welzl.pdf?format=raw

To fulfill part of the ICCRG charter, we need to put together an RFC
that describes these open issues in some depth.  A sort of "problem
statement" for each would be good, and could be used to direct future
work.  This follows onto the draft-iccrg-cc-rfcs (soon to be updated)
document because it explains the questions that aren't *yet* answered in
the RFC series, but that this RG would like to help develop good answers
for.

We need people to take this list of issues, expand on it if needed, and
turn it into a document.  If you would like to contribute to this as an
author/editor, please let the chairs (or the entire list) know.  We
don't need one person to write the whole document; each open issue could
be described in a different section written by a subset of co-authors,
so if you have specialized expertise to contribute text on a specific
issue, that's perfect.

If we could get even a very-rough 00 draft of this before Chicago, it
would be very good.  By the way, we're planning on meeting face-to-face
in conjunction with the IETF meeting in Chicago in July:
http://www.ietf.org/meetings/69-IETF.html
(more details will follow in the near future)

Thanks,
  Michael Welzl and Wesley Eddy

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Bob Briscoe)
Date: Wed Mar 21 14:00:32 2007
Subject: [Iccrg] Fwd: Unofficial BoF on "re-ECN architectural intent"
Message-ID: <[email-masked]>

Folks,

Unofficial BoF (starting in 12mins).

Wed 21 March 1510-1640 (90mins) in Karlin I.

I've arranged with Marcia for cookies & drinks to be left outside the room 
part-way through, so I've scheduled a 10min break to go hunting and gathering.

Slides are here
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#Presentations>
Loads of spare slides for whatever questions you fire at me.

Agenda is below (unchanged from previous announcement). Aaron Falk will 
kindly be chairing this.

Cheers

Bob

>Date: Tue, 20 Mar 2007 14:19:04 +0000
>To: DCCP mailing list <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Unofficial BoF on "re-ECN architectural intent"
>
>DCCPers,
>
>"The architectural intent of the re-ECN protocol"
>In Prague we'll be doing an unofficial 'Bar' BoF on this (see 
><http://www.ietf.org/tao.html> for what that is)
>
>Wed 21 March 1510-1640 in Karlin I.
>
>A number of people have asked for this, as they've found the short slots 
>in IETF w-gs aren't really suitable to discuss and challenge the intent of 
>what is effectively a proposal for major architectural change, albeit in 
>one bit.
>
>It's v relevant to DCCP, as it provides the environment for evolution of 
>"responsible" new congestion controls, but it gives much more freedom than 
>TCP-friendliness (I've explained why that's a broken concept anyway in ).
>
>Proposed Bar BoF agenda:
>Start 15:10
>1. [ 5mins] Administrivia
>2. [30mins] Architectural intent of re-ECN
>             (including a simple abstraction of how it works)
>3. [20mins] Questions & Answers
>4. [10mins] Is there community interest in working in this problem space?
>             IETF or IRTF?
>             How best to go about architectural change.
>             Next Steps.
>5. [10mins] I'll try to get cookies & drinks in the room.
>6. [15mins (squeezable/stretchable)] More questions & discussion.
>End 16:40
>
>Brief background and further links below...
>
>============================================================================
>The re-ECN protocol aims to make IP senders (including forwarders) 
>accountable for the pain they inflict on others (congestion). The re-ECN 
>protocol claims to allow different forms of congestion control to be 
>policed in different ways, or not policed at all, depending on policy.
>
>Embodied in re-ECN's design are implicit answers or deliberate non-answers 
>to many subtle architectural and policy issues:
>- who should decide on fairness?
>- how do we expect networks as a whole to police traffic from other networks?
>- what fairness policies might ISPs or groups of users want between them?
>- not just provider networks, but self-provided (incl. ad hoc) networks?
>- re-ECN claims to allow evolvability of congestion control. Assumptions?
>- it claims to mitigate DDoS and provide the right incentives to fix it. How?
>- it claims to do QoS more simply? Sure?
>- how does re-ECN relate to routing?
>- what about cheating?
>- should we control the sender or the receiver or both?
>- doesn't this just move the policing problem up a layer?
>- what about layered networks (IP over MPLS, ethernet, IP in IP etc)?
>- what likely outcome will we see for the Internet with this?
>- what if we do nothing?
>- why doesn't it solve world hunger?
>
>
>Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
><http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-03.txt>
>
>Full list of supporting documentation and papers:
><http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/>
>
>
>
>Bob
>
>
>____________________________________________________________________________
>Notice: This contribution is the personal view of the author and does not 
>necessarily reflect the technical nor commercial direction of BT plc.
>____________________________________________________________________________
>Bob Briscoe,                           Networks Research Centre, BT Research
>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

From: [email-masked] (Lachlan Andrew)
Date: Sat Mar 17 09:16:48 2007
Subject: [Iccrg] improvement of tcp slow start
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetigns Stefan,

On 17/03/07, Stefan Hirschmann <[email-masked]> wrote:
> In the average scenarios, it can happen, that current +=1 makes a bigger
> overshoot than +=2, e.g. with 8 KByte/sec. You have 1,2,4,8,16
> overshoot=16-8=8. But with +=2 you have 1,3,9, overshoot=9-8=1.

No.  The sequence 1, 2, 4, ... only applies once per RTT, but the
window increments are every packet.  That quantisation makes all the
difference in your example.

Both will cause loss   as soon as   the cwnd exceeds the BDP + buffer.
 Both will take one RTT to respond.  The one which triples the window
each RTT will have a cwnd of 3*(BDP+buffer), and the one which doubles
the window each RTT will have 2*(BDP+buffer).  This doesn't depend on
the capacity or the link, or the buffer size.

>  > [...] see the recent discussion on the end2end-interest list [...]
> I didn't found this discussion. I looked for march and february. Can you
> tell me the topic, because I would like to read it?

It started as "Are we doing sliding window in the Internet?"

> > What would be more useful would be something which can detect when
> > slow-start is nearing its end -- like measuring queueing delay or some
> > property of the RTT-level burstiness -- so that we can start
> > aggressively but back off when we're nearing the end.
> This idea sounds interesting.
> But what is the best way dealing with changing routes, that can also
> change the RTT (or wireless connection with the resend of broken packets)?

You're right that routing changes are important, but if slow start is
fast enough then routing changes during slow start should not be
common enough to optimise for them.  Of course there should be some
"failsafe" in case they do occur.

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] (Stefan Hirschmann)
Date: Fri Mar 16 19:56:48 2007
Subject: [Iccrg] improvement of tcp slow start
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi!

Lachlan Andrew schrieb:
> Greetings Stefan,
>
> The main problem with increasing the rate of increase of slow start is
> that it creates larger overshoot when the correct rate is reached.  If
> we triple the rate each RTT instead of doubling it (or multiplying by
> 1.5 -- see the recent discussion on the end2end-interest list), then
> we are transmitting at three times too fast when we finish.

Youre argument is a good one. But it is only so in the extreme 
szenarios, where cwnd=maxBandWith.
In the average szenarios, it can happen, that current +=1 makes a bigger 
overshoot than +=2, e.g. with 8 KByte/sec. You have 1,2,4,8,16  
overshoot=16-8=8. But with +=2 you have 1,3,9, overshoot=9-8=1. So in 
some cases, the +=2 may be even better, than the current +=1; I made a 
tabulary with the most common speeds in the internet:
===========================================================================
max Speed is in KBit/s and in () is the value for KByte/s, but Plus1, 
Plus2, Plus3 are in KByte/sec
max Speed [KBit/s] (in KByte/s)   Plus1    Plus2    Plus3
56 (7)                       5                    2        5
64 (8)                       4                    1        4
128 (16)                   8                   11        32
512 (64)                   32                17        128
768  (96)                  96              147        96
1024 (128)               64              115        64
2048  (256)              128            473        512
3072  (384)              384            345        384
4096  (512)              256            217        256
10240 (1280)           256            907        1792
102400 (12800)   11776            6883       36352
===========================================================================
As you can see, sometimes the plus2 is much better (e.g. 100MBit), in 
other cases it is worser.  I don't think that it is has any sense to 
make a mean or median over tit, because you have to use the real 
bandWith distribution in the internet. In this table the worst cases are 
in percentage (overshoot+bandwith)./bandwith :
===========================================================================
| Format: Plus1    Plus2    Plus3
| Min: 1.2000    1.1250    1.5000
| Max:  2.0000    2.8477    3.8400
| Mean: 1.6213    1.7463    2.3140
| Median:  1.5000    1.6875    2.0000
===========================================================================
Like already said, the mean and median should not messed too much, but 
if you say, that this type of connection are all used equal, than the 
number of overshoot packaged would increase by 18%. But most of the file 
transfer does'nt leave the slowStart, so this problem is in praxis much 
smaller. A connection has to transfer at least 60KByte (for plus2, plus1 
were 100 KByte) to leave the slow start for a 1MBit/s, so many 
WebTraffic won't even make an overhead.

But maybe it would be a good idea, to look, at which cwnd the biggest 
overshoot is, and be less aggressive in this area. Something like:
if (criticalArea)
    tp->snd_cwnd++
else
    tp->snd_cwnd+=2;

 > [...] see the recent discussion on the end2end-interest list [...]
I didn't found this discussion. I looked for march and february. Can you 
tell me the topic, because I would like to read it?

> What would be more useful would be something which can detect when
> slow-start is nearing its end -- like measuring queueing delay or some
> property of the RTT-level burstiness -- so that we can start
> aggressively but back off when we're nearing the end.
This idea sounds interesting. I don't know how complicated it is to 
implement. Maybe you make a simulation and look how effizient it works.
But what is the best way dealing with changing routes, that can also 
change the RTT (or wireless connection with the resend of broken packets)?

> There are also fairness issues with having some sources using  
> "improved" slow start and some using the existing algorithm, although
> I think they're often overstated.
I hope that the internet connection of the most server is good enough, 
that it can stand the slow start phase ;)
To be serious: It is true, that you get more packets than someone use 
the conventionell plus1. But: After the slow start it is equal, and if 
you loose a packet because of the congestion, you restart by 1, like the 
other one. If the connection is good enough, that the congestion 
avoidance phase is possible, both will reach them.

Cheers Stefan

From: [email-masked] (Michael Welzl)
Date: Fri Mar 16 07:23:44 2007
Subject: [Iccrg] improvement of tcp slow start
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2007-03-16 at 14:45 +1100, Lachlan Andrew wrote:
> Greetings Stefan,
> 
> The main problem with increasing the rate of increase of slow start is
> that it creates larger overshoot when the correct rate is reached.  If
> we triple the rate each RTT instead of doubling it (or multiplying by
> 1.5 -- see the recent discussion on the end2end-interest list), then
> we are transmitting at three times too fast when we finish.
> 
> What would be more useful would be something which can detect when
> slow-start is nearing its end -- like measuring queueing delay or some
> property of the RTT-level burstiness -- so that we can start
> aggressively but back off when we're nearing the end.

That sounds like a really good idea to me!

> There are also fairness issues with having some sources using
> "improved" slow start and some using the existing algorithm, although
> I think they're often overstated.

I agree (i.e. I also think they're overstated). In a world where
non-TCP-friendly highspeed TCP variants are already used, who
cares about one flow starting up a bit faster than the other,
especially when it would make a major difference in performance
for most real (i.e. short) flows?

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Fri Mar 16 03:46:08 2007
Subject: [Iccrg] improvement of tcp slow start
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Stefan,

The main problem with increasing the rate of increase of slow start is
that it creates larger overshoot when the correct rate is reached.  If
we triple the rate each RTT instead of doubling it (or multiplying by
1.5 -- see the recent discussion on the end2end-interest list), then
we are transmitting at three times too fast when we finish.

What would be more useful would be something which can detect when
slow-start is nearing its end -- like measuring queueing delay or some
property of the RTT-level burstiness -- so that we can start
aggressively but back off when we're nearing the end.

There are also fairness issues with having some sources using
"improved" slow start and some using the existing algorithm, although
I think they're often overstated.

Cheers,
Lachlan

On 16/03/07, Stefan Hirschmann <[email-masked]> wrote:
> Hi!
>
> I made a few thoughts about the tcp slow start behavior (each paket
> increases the window by 1, so that the value is doubled each RTT). But I
> think this behaviour is to slow, so that most of the connection can not
> use the maximum speed.
>
> I wrote a TCP slow start simulator <http://nopaste.debianforum.de/5415>
> . The output is:
> time[ms]   currend send window[1]      current used bandwith[KB/s]
> already sended data[KByte]
>
> If you look at the output:
> =============================================================
> $: ./slowStartSimulator 102400 1.5 500 1 1
> bandWith = 102400
> time   snd_cwnd  used_bandWith   alreadySended
> 0           1          3.0             0.0
> 500         2          6.0             1.5
> 1000        4         12.0             4.5
> 1500        8         24.0            10.5
> 2000       16         48.0            22.5
> 2500       32         96.0            46.5
> 3000       64        192.0            94.5
> 3500      128        384.0           190.5
> 4000      256        768.0           382.5
> 4500      512       1536.0           766.5
> 5000     1024       3072.0          1534.5
> 5500     2048       6144.0          3070.5
> 6000     4096      12288.0          6142.5
> 6500     8192      24576.0         12286.5
> 7000    16384      49152.0         24574.5
> 7500    32768      98304.0         49150.5
> 8000    65536     196608.0         98302.5
> USAGE: ./slowStartSimulator bandwith packetSize pingTime [adder multiplier]
>         everything in KB and ms
> =============================================================
> You see that it takes 8 seconds till the TCP flow reaches 100MB/s at a
> pingTime from 500ms (realistic for satellite uplinks distance = 4 * 36000).
>
> So I thought about improvements. If you change the std behaviour
> (tp->snd_cwnd++;) with multiply by 3(tp->snd_cwnd+=2) you get this output:
> =============================================================
> $slowStartSimulator 102400 1.5 500 2 1
> bandWith = 102400
> time   snd_cwnd  used_bandWith   alreadySended
> 0           1          3.0             0.0
> 500         3          9.0             1.5
> 1000        9         27.0             6.0
> 1500       27         81.0            19.5
> 2000       81        243.0            60.0
> 2500      243        729.0           181.5
> 3000      729       2187.0           546.0
> 3500     2187       6561.0          1639.5
> 4000     6561      19683.0          4920.0
> 4500    19683      59049.0         14761.5
> 5000    59049     177147.0         44286.0
> USAGE: ./slowStartSimulator bandwith packetSize pingTime [adder multiplier]
>         everything in KB and ms
> =============================================================
> Now it takes only 5 seconds till the 100 MB/s is reached.
>
>
> If you use (tp->snd_cwnd+=3); you get this output:
> =============================================================
> slowStartSimulator 102400 1.5 500 3 1
> bandWith = 102400
> time   snd_cwnd  used_bandWith   alreadySended
> 0           1          3.0             0.0
> 500         4         12.0             1.5
> 1000       16         48.0             7.5
> 1500       64        192.0            31.5
> 2000      256        768.0           127.5
> 2500     1024       3072.0           511.5
> 3000     4096      12288.0          2047.5
> 3500    16384      49152.0          8191.5
> 4000    65536     196608.0         32767.5
> USAGE: ./slowStartSimulator bandwith packetSize pingTime [adder multiplier]
>         everything in KB and ms
> =============================================================
> Now it takes only 4 seconds, till the 100MB/s is reached.
>
> I also tried to replace (tp->snd_cwnd++;) with something like
> (tp->snd_cwnd *= 2) but I think this is to aggressive and should not be
> used:
> =============================================================
> $slowStartSimulator 1024 1.5 500 0 2
> bandWith = 1024
> time   snd_cwnd  used_bandWith   alreadySended
> 0           1          3.0             0.0
> 500         2          6.0             1.5
> 1000        8         24.0             4.5
> 1500     2048       6144.0            16.5
> =============================================================
>
> Summary:
> The slowstart algorithm is from a time, where 56k modems where state of
> the art, but it is too less aggressive for todays networks. So I suggest
> to replace it with +=2 or +=3.
>
> What do you think about this? I made the programm with much care, but
> maybe I overlooked a bug, so if you want, check it too.
>
>
> Stefan
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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] (Stefan Hirschmann)
Date: Thu Mar 15 14:38:56 2007
Subject: [Iccrg] improvement of tcp slow start
Message-ID: <[email-masked]>

Hi!

I made a few thoughts about the tcp slow start behavior (each paket 
increases the window by 1, so that the value is doubled each RTT). But I 
think this behaviour is to slow, so that most of the connection can not 
use the maximum speed.

I wrote a TCP slow start simulator <http://nopaste.debianforum.de/5415> 
. The output is:
time[ms]   currend send window[1]      current used bandwith[KB/s]      
already sended data[KByte]

If you look at the output:
=============================================================
$: ./slowStartSimulator 102400 1.5 500 1 1
bandWith = 102400
time   snd_cwnd  used_bandWith   alreadySended
0           1          3.0             0.0
500         2          6.0             1.5
1000        4         12.0             4.5
1500        8         24.0            10.5
2000       16         48.0            22.5
2500       32         96.0            46.5
3000       64        192.0            94.5
3500      128        384.0           190.5
4000      256        768.0           382.5
4500      512       1536.0           766.5
5000     1024       3072.0          1534.5
5500     2048       6144.0          3070.5
6000     4096      12288.0          6142.5
6500     8192      24576.0         12286.5
7000    16384      49152.0         24574.5
7500    32768      98304.0         49150.5
8000    65536     196608.0         98302.5
USAGE: ./slowStartSimulator bandwith packetSize pingTime [adder multiplier]
        everything in KB and ms
=============================================================
You see that it takes 8 seconds till the TCP flow reaches 100MB/s at a 
pingTime from 500ms (realistic for satellite uplinks distance = 4 * 36000).

So I thought about improvements. If you change the std behaviour 
(tp->snd_cwnd++;) with multiply by 3(tp->snd_cwnd+=2) you get this output:
=============================================================
$slowStartSimulator 102400 1.5 500 2 1
bandWith = 102400
time   snd_cwnd  used_bandWith   alreadySended
0           1          3.0             0.0
500         3          9.0             1.5
1000        9         27.0             6.0
1500       27         81.0            19.5
2000       81        243.0            60.0
2500      243        729.0           181.5
3000      729       2187.0           546.0
3500     2187       6561.0          1639.5
4000     6561      19683.0          4920.0
4500    19683      59049.0         14761.5
5000    59049     177147.0         44286.0
USAGE: ./slowStartSimulator bandwith packetSize pingTime [adder multiplier]
        everything in KB and ms
=============================================================
Now it takes only 5 seconds till the 100 MB/s is reached.

If you use (tp->snd_cwnd+=3); you get this output:
=============================================================
slowStartSimulator 102400 1.5 500 3 1
bandWith = 102400
time   snd_cwnd  used_bandWith   alreadySended
0           1          3.0             0.0
500         4         12.0             1.5
1000       16         48.0             7.5
1500       64        192.0            31.5
2000      256        768.0           127.5
2500     1024       3072.0           511.5
3000     4096      12288.0          2047.5
3500    16384      49152.0          8191.5
4000    65536     196608.0         32767.5
USAGE: ./slowStartSimulator bandwith packetSize pingTime [adder multiplier]
        everything in KB and ms
=============================================================
Now it takes only 4 seconds, till the 100MB/s is reached.

I also tried to replace (tp->snd_cwnd++;) with something like 
(tp->snd_cwnd *= 2) but I think this is to aggressive and should not be 
used:
=============================================================
$slowStartSimulator 1024 1.5 500 0 2
bandWith = 1024
time   snd_cwnd  used_bandWith   alreadySended
0           1          3.0             0.0
500         2          6.0             1.5
1000        8         24.0             4.5
1500     2048       6144.0            16.5
=============================================================

Summary:
The slowstart algorithm is from a time, where 56k modems where state of 
the art, but it is too less aggressive for todays networks. So I suggest 
to replace it with +=2 or +=3.

What do you think about this? I made the programm with much care, but 
maybe I overlooked a bug, so if you want, check it too.

Stefan

From: [email-masked] (Bob Briscoe)
Date: Thu Mar 15 00:29:52 2007
Subject: [Iccrg] Bar BoF on "re-ECN architectural intent"
Message-ID: <[email-masked]>

IETF TSVWG, TSV-AREA, IRTF ICCRG,

"The architectural intent of the re-ECN protocol"
In Prague we'll be doing an unofficial Bar BoF on this (see 
<http://www.ietf.org/tao.html>)

Wed 21 March 1510-1640 in Karlin I.

A number of people have asked for this, as they've found the short slots in 
IETF w-gs aren't really suitable to discuss and challenge the intent of 
what is effectively a major architectural change, albeit in one bit.

Proposed Bar BoF agenda:
Start 15:10
1. [ 5mins] Administrivia
2. [30mins] Architectural intent of re-ECN
             (including a simple abstraction of how it works)
3. [20mins] Questions & Answers
4. [10mins] Is there community interest in working in this problem space?
             IETF or IRTF?
             How best to go about architectural change.
             Next Steps.
5. [10mins] I'll try to get cookies & drinks in the room.
6. [15mins (squeezable/stretchable)] More questions & discussion.
End 16:40

Brief background and further links below...

============================================================================
The re-ECN protocol aims to make IP senders (including forwarders) 
accountable for the pain they inflict on others (congestion). The re-ECN 
protocol claims to allow different forms of congestion control to be 
policed in different ways, or not policed at all, depending on policy.

Embodied in re-ECN's design are implicit answers or deliberate non-answers 
to many subtle architectural and policy issues:
- who should decide on fairness?
- how do we expect networks as a whole to police traffic from other networks?
- what fairness policies might ISPs or groups of users want between them?
- not just provider networks, but self-provided (incl. ad hoc) networks?
- re-ECN claims to allow evolvability of congestion control. Assumptions?
- it claims to mitigate DDoS and provide the right incentives to fix it. How?
- it claims to do QoS more simply? Sure?
- how does re-ECN relate to routing?
- what about cheating?
- should we control the sender or the receiver or both?
- doesn't this just move the policing problem up a layer?
- what about layered networks (IP over MPLS, ethernet, IP in IP etc)?
- what likely outcome will we see for the Internet with this?
- what if we do nothing?
- why doesn't it solve world hunger?

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-03.txt>

Full list of supporting documentation and papers:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/>

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196  

From: [email-masked] (Lars Eggert)
Date: Mon Mar 12 08:10:40 2007
Subject: [Iccrg] bringing experimental congestion control to the IETF
Message-ID: <[email-masked]>

Hi,

the attentive reader of IETF agendas will have picked up on the  
following presentation during the TSVAREA meeting:

20 min	Bringing Experimental High-Speed Congestion Control to the IETF
	Lars Eggert

I'd like to outline what that presentation will be about, for the  
benefit of those who can't travel to Prague. It will propose an  
approach for specifying high-speed congestion control in IETF  
Experimental RFCs for the community to discuss and hopefully form a  
consensus on.

For a number of years, there has been considerable interest in the  
research community on TCP extensions for high-speed networks that has  
resulted in a number of promising congestion control variants.  
Bandwidths that had been considered "high-speed" years ago are now  
readily available to consumers in many countries, resulting in a  
corresponding interest by the operating system community to deliver  
mechanisms to the users that can efficiently utilize these kinds of  
uplinks. Several widely-deployed operating systems already implement  
non-RFC-compliant congestion control mechanisms. This is happening  
without much community review and often without a publicly available  
technical specification, which is troubling.

The proposal is that the IETF and IRTF offer to be a venue for  
community discussion and review, followed by an eventual technical  
specification of such congestion control variants. The  two initial  
goals are (1) at a minimum, to document the mechanisms in currently  
deployed stacks in Informational RFCs and (2) to publish a number of  
more thoroughly analyzed congestion control variants as Experimental  
RFCs.

For the first class of documents, there will be a clear statement  
calling out that the contents of these Informational drafts document  
the implementation choices of particular stacks and are not  
recommendations, endorsements, etc. by the IETF. We've been  
publishing such documents in the past.

The second class of (Experimental) documents will be published with  
statements that indicate that the IETF believes them to be safe for  
experimentation on the Internet, or safe for experimentation in  
certain more restricted network environments. This is similar, for  
example, to the statements the IETF made for QuickStart or HighSpeed  
TCP. We are currently aware of at least three congestion control  
variants that have been proposed for such Experimental specification.

To be able to make such statements about Experimental congestion  
control variants, a review phase needs to occur in the community. The  
proposal is to use the expertise in the IRTF's congestion control  
research group during the initial phase of that review process. The  
proposers of high-speed congestion control variants will present  
their mechanism and results to the ICCRG, which will analyze and  
discuss these variants with the goal of determining whether they can  
be declared safe for experimentation, and under which conditions.  
draft-ietf-tsvwg-cc-alt and draft-irtf-tmrg-metrics contain some  
guidelines and metrics that will be useful during this review.

The ICCRG review phase will be followed by technical specification in  
the Transport Area in Experimental RFCs. The proposal is to add a  
work item to the charter of the TCPM working group for the  
Experimental standardization of such ICCRG-reviewed congestion  
control variants.

Lars

PS: Please discuss on [email-masked]. Reply-to set accordingly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070312/bf34977a/smime.bin
>From [email-masked]  Mon Mar 12 09:06:08 2007
From: [email-masked] (Lars Eggert)
Date: Mon Mar 12 09:08:16 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2007-3-9, at 22:46, ext Mark Allman wrote:
> (3) The test scenarios need not be completely static.  That is, the  
> RTTs
>     / cross traffic / packet corruption rate / reordering / whatever
>     should probably be varied randomly (with a number of trials of
>     course).

I had this halfbaked idea of looking at randomized topologies for  
protocol evaluation as picking points in one large multidimensional  
parameter space. There are some math techniques for finding the  
interesting points in such a parameter space, but you'd need the  
hardware to run a LOT of ns2 experiments in parallel. I wonder if  
DETER has spare capacity?

And the danger remains that for any given proposal, the interesting  
stuff happens outside of the chosen parameter space...

Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070312/aedaa4a2/smime.bin
>From [email-masked]  Mon Mar 12 17:55:12 2007
From: [email-masked] (Sally Floyd)
Date: Mon Mar 12 17:57:20 2007
Subject: [Iccrg] feedback on draft-irtf-tmrg-metrics?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Michael -

Many thanks for the feedback.

> I read it, and think it's a really useful document. I just
> have some minor comments:

I made all of the changes that you suggested, and the revised
version is at
"http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-09.txt".

I am going to send email to the tmrg mailing list now,
checking that there is still consensus for forwarding this
to the IRTF for review and publication as Informational.

Again, many thanks.
- Sally
http://www.icir.org/floyd/

From: [email-masked] (Mark Allman)
Date: Sat Mar 10 03:50:24 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> [Mark Allman:]
> > (2) We need to make sure that schemes are not tailored to the test
> >     scenarios.  Perhaps someone would actively try to do this.  However,
> >     my bigger concern is that such a set of generic simulations would
> >     lock folks into particular mental models of networks that would lead
> >     them to implicitly design towards the scenarios and not for broader
> >     situations.
> 
> This is my greatest concern. But then, a standard suite also forces
> folks away from using only their own tailored scenarios where their
> design works best.

That is absolutely true and that happens far too often.

I think it is just vital that the accepted view of these developed
scenarios is that they are only part of the story and that additional
tests and analysis will very likely be needed for a specific study.

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/20070309/16de6a81/attachment.bin
>From [email-masked]  Sun Mar 11 19:54:40 2007
From: [email-masked] (Douglas Leith)
Date: Sun Mar 11 19:56:48 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> It seems to me that the scenarios should (i) be generic  
> (exhaustive?) enough to capture most common ones, and at the same  
> time (ii) be small enough in number that reporting results for  
> these tests does not take up 500 graphs and therefore encourages  
> folks to do more than just these tests.
>
> I love the idea of scripting these into ns.
>

For what its worth, I'd echo Mark and Wesley's sentiments.

Re ns scripting, some of the groundwork is already done (including  
html interfacing to see the results e.g. so they can be easily placed  
on the web).  Take a look at http://www.hamilton.ie/net/eval/ 
tcptesting.zip.  Its all pretty simple shell scripts, so very open  
and easy to extend.  As there's a clean interface to ns, its also  
easy to recycle this code to run experimental tests.

Doug

From: [email-masked] (Janardhan Iyengar)
Date: Fri Mar  9 22:26:08 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Having a suite of such tests is a great idea, but I feel there is a 
tradeoff in there somewhere.

[Mark Allman:]
> (2) We need to make sure that schemes are not tailored to the test
>     scenarios.  Perhaps someone would actively try to do this.  However,
>     my bigger concern is that such a set of generic simulations would
>     lock folks into particular mental models of networks that would lead
>     them to implicitly design towards the scenarios and not for broader
>     situations. 

This is my greatest concern. But then, a standard suite also forces 
folks away from using only their own tailored scenarios where their 
design works best.

It seems to me that the scenarios should (i) be generic (exhaustive?) 
enough to capture most common ones, and at the same time (ii) be small 
enough in number that reporting results for these tests does not take up 
500 graphs and therefore encourages folks to do more than just these tests.

I love the idea of scripting these into ns.

- jana

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/

From: [email-masked] (ext Lars Eggert)
Date: Tue Mar  6 15:40:48 2007
Subject: [Iccrg] preliminary TSVAREA agenda for Prague
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

TSVAREA Agenda for IETF-68 (Prague)
TUESDAY, March 20, 2007
1520-1720 Afternoon Session II
Congress III

10 min	Note Well
	Scribes
	Agenda Bashing

10 min	New WG Overview: Congestion and Pre-Congestion Notification (PCN)
	Scott Bradner and Steven Blake

20 min	Bringing Experimental High-Speed Congestion Control to the IETF
	Lars Eggert
	
20 min	Vista Implementation Report on ECN/FRTO/WS/DSACK
	Dave Thaler and Murari Sridharan
	
Please email additional agenda requests to [email-masked].

The purpose of the TSVAREA meeting is to inform about and discuss  
important issues, developments and work within the transport area or  
outside work that impacts the transport area. In contrast to TSVWG,  
TSVAREA does not produce any documents. TSVAREA can include tutorial- 
style talks on tranport topics, maybe based on related IRTF or other  
research work. Again, we encourage relevant presentations from both  
within the transport area and from outside parties, such as other  
IETF WGs or the IRTF.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070306/851294d7/smime.bin
>From [email-masked]  Thu Mar  8 05:32:48 2007
From: [email-masked] (Yong Xia)
Date: Thu Mar  8 05:34:56 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
Message-ID: <[email-masked]>

Hi Wesley,

Just saw you post. And I thought you might be interested in a project we are
working on with our collabrators. It is an ns2 TCP simulation tool suite.
This suite includes a number of typical network topologies, with settable
link capacities and traffic matrix. After a simulatioin completes, it
automatically generates a set of performance metrics (part of Dr. Sally
Floyd's TMRG draft) and graphs, and, with minimal manual effort, can put all
the statistics into an HTML page or a paper. We have used this tool suite
to evaluate ten protocols with over 10,000 simulations.

We will publish an IETF draft to describe our work and the code shortly.

Best,
Yong Xia
NEC Labs China

---------- Forwarded message ----------
From: Wesley Eddy <[email-masked]>
To: Douglas Leith <[email-masked]>
Date: Tue, 6 Mar 2007 09:42:53 -0500
Subject: Re: [Iccrg] benchmarking new tcp congestion control algorithms
On Sun, Feb 11, 2007 at 12:28:36PM +0000, Douglas Leith wrote:
>
> Just posted this to the end2end list, but in view of the discussions
> at pfldnet last week and the agenda for the iccrg meeting tomorrow,
> it might be topical for iccrg.
>
> I've put together a set of short ns scripts to carry out the tcp
> benchmark tests described in
>
> Experimental evaluation of high-speed congestion control protocols,
> Li, Y.T, Leith,D., Shorten,R. Transactions on Networking, 2007 (see
> http://www.hamilton.ie/net/eval/ToNfinal.pdf).
>
> The ns scripts are at http://www.hamilton.ie/net/eval/tcptesting.zip.
>
> Its now very easy to rerun these tests against proposed new
> congestion control algorithms.  Baseline tests for standard tcp, high-
> speed tcp, scalable tcp, bic tcp, fast tcp and htcp are reported in
> http://www.hamilton.ie/net/eval/ToNfinal.pdf and these experimental
> measurements can be directly compared against the simulation results
> generated by the script.
>
> Let me know if you have any comments.
>

I think these kinds of contributions are very helpful for the community.
I wonder if based on this, it would be possible to propose a "minimal"
set of test scenarios and objectives that we could use as a sort of
first stage of screening for new congestion control schemes.  If we
could come up with some rough consensus on what battery of test results
demonstrates that a given scheme is safe, then we could do to things:

1) leverage the set of tests as a fair and level way to achieve
  consensus that particular congestion control schemes that are
  proposed in the ICCRG are safe to be published as Experimental.

2) use the test output to refine proposed congestion control schemes,
  tweak parameters, and understand the differences between schemes

All around I think a standard battery of tests and some goals for the
tests based on the tmrg-metrics work would be fantastically useful.
Does anyone else agree or have cycles to work on this kind of
infrastructure for the group?

--
Wesley M. Eddy
Verizon Federal Network Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070308/68fe77ba/attachment.html
>From [email-masked]  Thu Mar  8 05:52:00 2007
From: [email-masked] (Yong Xia)
Date: Thu Mar  8 05:52:00 2007
Subject: [iccrg] performance comparison on high-speed tcp protocols
Message-ID: <[email-masked]>

Hi,

We have conducted extensive ns2 simulations to evaluate some of the recently
proposed high-speed TCP protocols. The case we consider is that, in the long
run, we have the freedom to deploy AQM and ECN, which has better performance
(particularly, end-to-end latency, which is increasingly important to the
Internet with more and more VoIP traffic) than otherwise. (A great amount of
similar work has also been done, esp. without using AQM in the bottleneck
routers.)

We simulated ten protocols, i.e., SACK, Reno, HSTCP, HTCP, STCP, FAST, BIC,
CUBIC, XCP and VCP. For the first eight protocols, we run RED with ECN
enabled in the bottlenecks. The latter two protocols have their own router
algorithms, so they do not use RED. The details can be seen in our technical
report http://networks.ecse.rpi.edu/~xiay/pub/vcp_tr.ps. More information is
available at http://networks.ecse.rpi.edu/~xiay/vcp.html.

We welcome your comments. Thanks.

Yong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070308/dd229117/attachment.html
>From [email-masked]  Fri Mar  9 20:45:52 2007
From: [email-masked] (Mark Allman)
Date: Fri Mar  9 20:48:00 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> All around I think a standard battery of tests and some goals for the
> tests based on the tmrg-metrics work would be fantastically useful.

Good idea.  Several comments ...

(1) A strong note should be made that such a battery of generic and
    simple tests should not be the *only* tests one runs.  I.e., they
    should be considered a good start, not a complete set.

(2) We need to make sure that schemes are not tailored to the test
    scenarios.  Perhaps someone would actively try to do this.  However,
    my bigger concern is that such a set of generic simulations would
    lock folks into particular mental models of networks that would lead
    them to implicitly design towards the scenarios and not for broader
    situations. 

(3) The test scenarios need not be completely static.  That is, the RTTs
    / cross traffic / packet corruption rate / reordering / whatever
    should probably be varied randomly (with a number of trials of
    course).

My two bits for a Friday.

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/20070309/4814fb07/attachment.bin
>From [email-masked]  Fri Mar  9 21:05:04 2007
From: [email-masked] (Wesley Eddy)
Date: Fri Mar  9 21:09:20 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Fri, Mar 09, 2007 at 03:46:27PM -0500, Mark Allman wrote:
> 
> > All around I think a standard battery of tests and some goals for the
> > tests based on the tmrg-metrics work would be fantastically useful.
> 
> Good idea.  Several comments ...
> 
> (1) A strong note should be made that such a battery of generic and
>     simple tests should not be the *only* tests one runs.  I.e., they
>     should be considered a good start, not a complete set.
> 
> (2) We need to make sure that schemes are not tailored to the test
>     scenarios.  Perhaps someone would actively try to do this.  However,
>     my bigger concern is that such a set of generic simulations would
>     lock folks into particular mental models of networks that would lead
>     them to implicitly design towards the scenarios and not for broader
>     situations. 
> 
> (3) The test scenarios need not be completely static.  That is, the RTTs
>     / cross traffic / packet corruption rate / reordering / whatever
>     should probably be varied randomly (with a number of trials of
>     course).
> 

I agree with all of the above points.  My thought was that these would
be useful for "quick rejects" or "sanity tests" on proposals, but by no
means to be considered the final judge.

-- 
Wesley M. Eddy
Verizon Federal Network Systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070309/96824531/attachment.bin
>From [email-masked]  Fri Mar  9 21:24:16 2007
From: [email-masked] (Bob Briscoe)
Date: Fri Mar  9 21:26:24 2007
Subject: [Iccrg] Updated Fairness I-D: draft-briscoe-tsvarea-fair-01
Message-ID: <[email-masked]>

Folks,

I've posted a considerably updated version of the I-D I did on 
fairness.  (main changes itemised below). It's not appeared yet so pls use 
my own URL below for now.

Comments always welcome.

<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-briscoe-tsvarea-fair-01.pdf>

Summary of Changes
------------------
    Full diffs created using the excellent rfcdiff tool are available at
    <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-briscoe-tsvarea-fair-01-00.html>

    From -00 to -01:

       Toned down the polemic.

       Added Section 8 "Critiques of Specific Schemes", adding
       subsections on TCP and WFQ to previously disparate material on
       max-min fairness, TFRC & router-based fairness approaches like
       XCP, which have been shortened and clarified.  Also added
       subsections on TCP-style fairness wrt RTT and packet size that has
       been copied by other transports.

       Added substantial new Section 9 "Implications for the RFC Series".
       Added to the introduction the importance of the issue and the
       general implications.

       Created an expanded and clarified new subsection Section 5.2
       "Comparing Costs" from text previously at the end of Section 5.1
       "Something to Integrate the Allocations"

       Added quote on flow granularity from RFC2309 & RFC2914.

       Clarified and expanded Section 5.3.2 "Enforcing Cost Fairness".

       Various clarifications throughout.

Cheers

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

From: [email-masked] (Michael Welzl)
Date: Tue Mar  6 14:58:08 2007
Subject: [Iccrg] feedback on draft-irtf-tmrg-metrics?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear Sally,

I'm terribly sorry for waiting until the last minute; in fact
I didn't, it's just a matter of luck that I can still make
this just on time....

I read it, and think it's a really useful document. I just
have some minor comments:

Page 9, Paragraph under 3.3 heading: I would state that the
"fairness between TCP and a new transport protocol" is
commonly called "TCP-friendliness"; that term seems to be
missing in this document.

2 paragraphs below: I always found this definition of
max-min fairness a bit hard to grasp, and always liked
the fact that most authors explain the "progressive
filling algorithm" as a way of thinking about it. It would
be a nice service for readers to add a sentence of this
algorithm here.

3 paragraphs below (proportional fairness definition) -
here, you take the definition from Kelly's paper but
omit the definition of a "feasible allocation". Additionally,
I would again provide readers with an explanation that
makes it easier to understand the concept - you could
just say that proportional fairness is the outcome of
maximizing the log utility functions of all flows

page 11 2nd paragraph under heading 3.4: shouldn't
it be "In general, _THE_ Internet architecture has valued..." ?

Last sentence of last paragraph in this section: shouldn't
it be "lower interference _WITH_ other users"?

Maybe these two suggestions are wrong, as I'm not
a native English speaker - but then again, maybe they
are typos.

That's it!

Cheers,
Michael

On Tue, 2007-02-20 at 17:17 -0800, Sally Floyd wrote:
> "Metrics for the Evaluation of Congestion Control Mechanisms",
>   internet-draft draft-irtf-tmrg-metrics-07.txt, is available from:
>    http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-07.txt
>    http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-07.ps
> 
> This draft has finished review within the TMRG (Transport
> Modeling Research Group), and is ready to be passed to
> the IRTF for review and publication.  However, before I pass
> this to the IRTF, this is to pass it by ICCRG for feedback.
> If anyone would like to read it and give feedback, feedback
> would be appreciated in the next two weeks (that is,
> by March 6).  After that, I will forward the draft to IRTF
> for review and publication as an Informational RFC.
> 
> Many thanks,
> 
> - Sally
> http://www.icir.org/floyd/
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Wesley Eddy)
Date: Tue Mar  6 14:47:28 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, Feb 11, 2007 at 12:28:36PM +0000, Douglas Leith wrote:
> 
> Just posted this to the end2end list, but in view of the discussions  
> at pfldnet last week and the agenda for the iccrg meeting tomorrow,  
> it might be topical for iccrg.
> 
> I've put together a set of short ns scripts to carry out the tcp  
> benchmark tests described in
> 
> Experimental evaluation of high-speed congestion control protocols,  
> Li, Y.T, Leith,D., Shorten,R. Transactions on Networking, 2007 (see  
> http://www.hamilton.ie/net/eval/ToNfinal.pdf).
> 
> The ns scripts are at http://www.hamilton.ie/net/eval/tcptesting.zip.
> 
> Its now very easy to rerun these tests against proposed new  
> congestion control algorithms.  Baseline tests for standard tcp, high- 
> speed tcp, scalable tcp, bic tcp, fast tcp and htcp are reported in  
> http://www.hamilton.ie/net/eval/ToNfinal.pdf and these experimental  
> measurements can be directly compared against the simulation results  
> generated by the script.
> 
> Let me know if you have any comments.
> 

I think these kinds of contributions are very helpful for the community.
I wonder if based on this, it would be possible to propose a "minimal"
set of test scenarios and objectives that we could use as a sort of
first stage of screening for new congestion control schemes.  If we
could come up with some rough consensus on what battery of test results
demonstrates that a given scheme is safe, then we could do to things:

1) leverage the set of tests as a fair and level way to achieve
   consensus that particular congestion control schemes that are
   proposed in the ICCRG are safe to be published as Experimental.

2) use the test output to refine proposed congestion control schemes,
   tweak parameters, and understand the differences between schemes

All around I think a standard battery of tests and some goals for the
tests based on the tmrg-metrics work would be fantastically useful.
Does anyone else agree or have cycles to work on this kind of
infrastructure for the group?

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Wesley Eddy)
Date: Tue Mar  6 14:32:32 2007
Subject: [Iccrg] high-speed tcp workshop proceedings
Message-ID: <[email-masked]>

Prior to the ICCRG meeting last month, there was a workshop at Microsoft
research on high-speed TCP modifications.  Some proceedings (presentation
slides) from that workshop are on the web and might be interesting or
useful to people in the ICCRG:

http://research.microsoft.com/%7Epadhye/TCPWorkshop/

Thanks to Jitu Padhye for sharing these.

-- 
Wesley M. Eddy
Verizon Federal Network Systems