Subject: [Iccrg] draft-irtf-cc-rfcs
From: [email-masked] (Michael Welzl)
Date: Sat Apr 28 12:05:36 2007

Dear all,

Due to the little, and mostly positive feedback that we received
(only minor wording issues were now pointed out, and we will
fix them), Wesley and I would like to declare group consensus on
draft-irtf-iccrg-cc-rfcs-01
http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-01.txt
and take it to the next level.

Before we do this, we want to give you a 2 week deadline - so,
if we do not receive any substantially negative comments about the
document by Monday May 14, we will send it to the IRSG for
review, in accordance with the process described in draft-irtf-rfcs-00

Changes from the previous version can be seen here:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-irtf-iccrg-cc-rfcs-01.txt

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Sat Apr 28 11:48:32 2007
Subject: [Iccrg] Seeking more volunteers for the problem statement draft
Message-ID: <004101c78982$fca760d0$0200a8c0@fun>

So far, we have two - we'd like to have more.

Speak up if you'd like to contribute to the problem statement draft!

FYI,

This is the related charter statement:
"..as a starting point to achieve focus for the group, ICCRG will produce an
RFC describing the nature of the emerging congestion control problems that
any future congestion control architecture must face."

...and the last slide of my presentation at the last meeting:
http://www1.tools.ietf.org/group/irtf/trac/attachment/wiki/Agenda/michael_welzl.ppt
http://www1.tools.ietf.org/group/irtf/trac/attachment/wiki/Agenda/michael_welzl.pdf
contains an IETF specific list of issues that this draft could discuss. I'd
say that
we're talking about a lengthy document here.

Cheers,
Michael

From: [email-masked] (Lars Eggert)
Date: Fri Apr 20 10:59:28 2007
Subject: [Iccrg] Re: [tsv-area] consensus call: bringing new congestion control to the IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-4-6, at 11:01, ext Lars Eggert wrote:
> after the presentation at TSVAREA, there was strong consensus in  
> the room for the presented process to bring new congestion control  
> to the IETF. I'd like to confirm that the community as a whole has  
> consensus on this.
>
> Please take a look at the following draft ION, which describes the  
> process from the presentation: http://www.ietf.org/IESG/content/ 
> ions/drafts/ion-tsv-alt-cc.txt
>
> The consensus call will run until April 18, 2007. Please review the  
> draft ION and send comments by the deadline.

I have seen very few comments during this consensus call, but all  
where positive. Together with the strong positive feedback from  
Prague, my take is that we have community consensus on this  
procedure. If you think I'm misjudging the consensus, please yell.

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/20070420/0cd07467/smime.bin
>From [email-masked]  Fri Apr 27 16:00:16 2007
From: [email-masked] (Wesley Eddy)
Date: Fri Apr 27 16:02:24 2007
Subject: [Iccrg] chicago meeting
Message-ID: <[email-masked]>

I put in a request so that we can have a meeting sometime during IETF 69
in Chicago (July 22-27) : http://www.ietf.org/meetings/69-IETF.html.

I asked for a 2.5 hour timeslot that, if possible, shouldn't conflict
with tsvarea, tsvwg, tcpm, dccp, avt, rmt, pcn.  I also put in nemo and
dtnrg, as I may have to participate in these.  If there are other
important conflicts to avoid, please let me know promptly, so I can
edit the request.

In the meeting, we'll discuss progress and next steps and (I suspect)
have a lot of the time open for research presentations.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Lars Eggert)
Date: Fri Apr  6 09:02:08 2007
Subject: [Iccrg] consensus call: bringing new congestion control to the IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

On 2007-3-12, at 10:06, ext Lars Eggert wrote:
> 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

after the presentation at TSVAREA, there was strong consensus in the  
room for the presented process to bring new congestion control to the  
IETF. I'd like to confirm that the community as a whole has consensus  
on this.

Please take a look at the following draft ION, which describes the  
process from the presentation: http://www.ietf.org/IESG/content/ions/ 
drafts/ion-tsv-alt-cc.txt

The consensus call will run until April 18, 2007. Please review the  
draft ION and send comments by the deadline.

Assuming the consensus from Prague is confirmed, I will ask the IESG  
to approve the ION after April 18.

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/20070406/777647d7/smime.bin
>From [email-masked]  Fri Apr  6 17:36:16 2007
From: [email-masked] (Mark Allman)
Date: Fri Apr  6 17:36:16 2007
Subject: [Iccrg] improvement of tcp slow start
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I have read this thread and have a few comments ...

> But I think this behaviour is to slow, so that most of the connection
> can not use the maximum speed.
> 
> [...]
> 
> 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
>
> [...]
>
> 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:
>
> [...]
>
> 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.

(1) It is easy to make TCP's algorithms more aggressive and look at the
    positives and say "we should take that path".  But, you also have to
    look at the negatives and your simulation really does nothing except
    plot an exponential function with difference increase factors.  It
    is interesting to me in the above that you found a place that is
    "to[o] aggressive".  Why should we not use *= 2, but we should use
    += 2.  If you want to suggest a change in the factor then you need
    to actually figure out the pros and cons.

    E.g., the RTO estimator might get hosed if you build a queue faster
    than expected and so end up needlessly retransmitting and hosing
    performance.

    E.g., you have changed the worst possible case from sending twice as
    fast as the capacity can absorb to sending three or four times as
    fast.  What are the implications of this (for the connection using
    the change and the for competing traffic)?

(2) This is sort of an interesting note to me because a very long time
    ago I needed some 2 page paper for a class on TCP and given my
    procrastination I had about half an hour to do it.  So, I first
    suggested that we triple instead of double every RTT.  The bigger
    point I then tried to make was "why is 2 magic?".  I don't
    necessarily think 2 is magic.  We would need to be careful about
    changing it and making sure that change meshed well with the rest of
    TCP's algorithms and that we understood the implications.  It seems
    to me that you are simply proposing an out-of-the-air new magic
    number.  We shouldn't do that.

(3) There are plenty of suggestions for how to increase the speed of
    slow start and to try to grok when it is ending.  (From TCB sharing
    to swift start to the congestion manager to quick start to Hoe's
    work on figuring out when to end to ...)  Perhaps we should not
    bother with this parameter tweaking business, but pick a
    fundamentally better way to go.

    Or, perhaps we should get rid of the parameter---and the algorithm.
    The ridiculously stupid end of this spectrum is that initially you
    can send as fast as you want:

        Dan Liu, Mark Allman, Shudong Jin, Limin Wang.  Congestion
        Control Without a Startup Phase.  Protocols for Fast, Long
        Distance Networks (PFLDnet) Workshop, February 2007.
        http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf

    Sometimes it is OK.  Sometimes not.

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/20070406/9d604b22/attachment.bin
>From [email-masked]  Sun Apr  8 06:09:20 2007
From: [email-masked] (Sally Floyd)
Date: Sun Apr  8 06:09:20 2007
Subject: [Iccrg] update to cc-rfcs draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Wesley -

>  Michael and I feel
> that this summary is fairly complete at this point, and would like to
> wrap it up in the near future, so we'd appreciate some additional 
> reviews
> from the group.

I read it over, and it seems good to me.

Some fairly minor feedback is below.

In the description of RFC 2481, you might want to add that it is
obsoleted by RFC 3168 (even though that is also mentioned
two paragraphs down in the discussion of RFC 3168).

In the description of RFC 3540:
The semantics of the bit combination in question are specified in 
[RFC3168].
 From [RFC3168]:  "The use of two ECT codepoints essentially gives a
one-bit ECN nonce in packet headers."

So the first sentence would be more correct as follows:

"This document specifies a nonce mechanism that uses an ECN
bit combination that is not used in [RFC2481], but that is
specified in [RFC3168] to allow a one-bit ECN nonce.
This nonce mechanism includes the definition of a Nonce Sum ..."

Also in the description of RFC 3540:
"there is currently some controversy as to whether the
mechanism is really effective".
I am aware of the controversy of whether the nonce is the
best use of this codepoint, but I am not aware of any controversy
about whether the nonce mechanism is really effective at preventing
the receiver from lying about receiving packets undropped and
unmarked.

Typos:
Section 3:  "may discussed" -> "may be discussed".

- Sally
http://www.icir.org/floyd/

From: [email-masked] (Wesley Eddy)
Date: Wed Apr  4 19:16:32 2007
Subject: [Iccrg] update to cc-rfcs draft
Message-ID: <[email-masked]>

FYI, an updated version of the "summary of congestion control RFCs" I-D
is online at:
http://tools.ietf.org/html/draft-irtf-iccrg-cc-rfcs-01

There's a diff of what's changed between this and the last version at:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-irtf-iccrg-cc-rfcs-01.txt

I think the main changes are mostly additions of text that describes the
current deployment and usage (or lack of) for some of the mechanisms.

This should be useful for feeding into the work on defining open issues
and for evaluating new proposals, as it gives a mostly-complete picture
of what's been published already in the RFC series.  Michael and I feel
that this summary is fairly complete at this point, and would like to
wrap it up in the near future, so we'd appreciate some additional reviews
from the group.

-- 
Wesley M. Eddy
Verizon Federal Network Systems