Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
From: [email-masked] (Mark Allman)
Date: Thu Sep 20 05:47:22 2007

> On 19/09/2007, Mark Allman <[email-masked]> wrote:
> >
> > First, if the performance is driven by the magnitude of the RTO then
> > that is a more general problem than with the min RTO, I think.  We have
> > devised much better loss recovery than relying on the RTO and so one
> > would hope that RTOs are rare enough to not be driving performance.
> 
> True, but isn't RTO still required for windows less than 4 segments?

Sort of.  If one uses Limited Transmit (RFC3042) then no, not
necessarily.  But, of course, there are always cases whereby the RTO is
going to be required since the only thing we can actually count on is
the passage of time.  (Or, if we can't count on the passage of time then
who gives a damn, right?! :) )

> That is also the case in which resetting the window is least harmful.

Right.

Also, related to this is Early Retransmit which has been talked about
within the IETF on-and-off for quite a number of years and seems like it
is going to be taken on as a TCPM WG work item.  See
draft-allman-tcp-early-rexmt-05.txt.

> Could the optimal tradeoff possibly depend on the size of the window
> somehow, starting fairly agressive, and then plateauing for cwnd > 8
> or something?

I think someone could make a short-timeout sort of scheme for small
windows.  It'd need to be worked out, but it seems plausible to me.

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/20070919/917726e3/attachment.bin
>From [email-masked]  Thu Sep 20 09:41:08 2007
From: [email-masked] (Lars Eggert)
Date: Thu Sep 20 11:21:16 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi,

On 2007-9-20, at 0:58, ext Sushant Rewaskar wrote:
> We passively analyze more than 2.8 million real world connections  
> using a
> very detailed passive analysis tool named TCPdebug
...
> Based on our experiments we have identified several changes to TCP  
> like -
...
> (ii) Reduce minimum retransmission timeouts to 200ms or lower

did any of these traces include GSM or UMTS access links? Because  
they have transmission delays that can be significantly higher than  
200ms.

This is the first few lines of a quick traceroute I took just now  
over my UMTS link:

# traceroute 128.9.160.161
traceroute to 128.9.160.161 (128.9.160.161), 64 hops max, 40 byte  
packets
  1  213-161-41-72 (213.161.41.72)  245.816 ms  223.566 ms  197.966 ms
  2  213-161-41-82 (213.161.41.82)  207.938 ms  230.286 ms  230.970 ms
  3  rl032002.radiolinja.fi (213.161.32.2)  236.970 ms  229.547 ms   
225.996 ms
...

GSM is much worse.

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/20070920/204febd3/smime-0001.bin
>From [email-masked]  Thu Sep 20 12:45:38 2007
From: [email-masked] (Mark Allman)
Date: Thu Sep 20 14:29:43 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> On 2007-9-20, at 0:58, ext Sushant Rewaskar wrote:
> > We passively analyze more than 2.8 million real world connections
> > using a
> > very detailed passive analysis tool named TCPdebug
> ...
> > Based on our experiments we have identified several changes to TCP
> > like -
> ...
> > (ii) Reduce minimum retransmission timeouts to 200ms or lower
> 
> did any of these traces include GSM or UMTS access links? Because
> they have transmission delays that can be significantly higher than
> 200ms.

Lars-

I am not sure I follow here.  Are you saying that the min RTO that is
(/was) preventing some sort of bad behavior in networks with GSM or UMTS
components?

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/20070920/f67d7934/attachment.bin
>From [email-masked]  Thu Sep 20 13:01:00 2007
From: [email-masked] (Lars Eggert)
Date: Thu Sep 20 14:40:49 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2007-9-20, at 14:45, ext Mark Allman wrote:
>> On 2007-9-20, at 0:58, ext Sushant Rewaskar wrote:
>>> (ii) Reduce minimum retransmission timeouts to 200ms or lower
>>
>> did any of these traces include GSM or UMTS access links? Because
>> they have transmission delays that can be significantly higher than
>> 200ms.
>
> I am not sure I follow here.  Are you saying that the min RTO that is
> (/was) preventing some sort of bad behavior in networks with GSM or  
> UMTS
> components?

Hm.

When I wrote the above, for some reason I was worried about this  
causing spurious timeouts. But thinking about this again, it probably  
won't in most cases, because it's the minimum that we're talking  
about, i.e., what you round up to when the timeout is calculated to  
be smaller.

(It might still cause spurious timeouts in some rare cases, such as  
when the path delay suddenly jumps from < 200ms to >> 200ms, but  
that's a corner case.)

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/20070920/976bdc3b/smime.bin

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

Greetings Mark,

On 19/09/2007, Mark Allman <[email-masked]> wrote:
>
> First, if the performance is driven by the magnitude of the RTO then
> that is a more general problem than with the min RTO, I think.  We have
> devised much better loss recovery than relying on the RTO and so one
> would hope that RTOs are rare enough to not be driving performance.

True, but isn't RTO still required for windows less than 4 segments?
That is also the case in which resetting the window is least harmful.

Could the optimal tradeoff possibly depend on the size of the window
somehow, starting fairly agressive, and then plateauing for   cwnd > 8
  or something?

Sushant, perhaps you could see what impact that would have based on your traces.

Cheers,
Lachlan

(BTW,  the "it" which I was speculating shouldn't be an issue is the
presence of coarse grained clocks, stated as the reason for needing to
be conservative.  Jitter could still be an issue, but clock
granularity shouldn't.)

-- 
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] (Mark Allman)
Date: Wed Sep 19 23:46:31 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

[I answered this on the TCPM list where Ian also posted it.  I am just
 now doing a little catchup on the ICCRG list and so I will replay my
 answer here.  --allman]

Ian-

> After some discussion on the Linux networking list I thought I'd ask
> the question here.
> 
> In RFC 2988 Section 2.4 says:
>   (2.4) Whenever RTO is computed, if it is less than 1 second then the
>         RTO SHOULD be rounded up to 1 second.
> 
>         Traditionally, TCP implementations use coarse grain clocks to
>         measure the RTT and trigger the RTO, which imposes a large
>         minimum value on the RTO.  Research suggests that a large
>         minimum RTO is needed to keep TCP conservative and avoid
>         spurious retransmissions [AP99].  Therefore, this
>         specification requires a large minimum RTO as a conservative
>         approach, while at the same time acknowledging that at some
>         future point, research may show that a smaller minimum RTO is
>         acceptable or superior.
> 
> Given that Linux, BSD etc use 200 milliseconds, not 1 second I am
> wondering whether there has in fact been any research done as
> mentioned in last sentence. 

I am not aware of any.

> It seems a very high timeout especially on two locally connected
> devices.

Well, a couple of things .... 

First, if the performance is driven by the magnitude of the RTO then
that is a more general problem than with the min RTO, I think.  We have
devised much better loss recovery than relying on the RTO and so one
would hope that RTOs are rare enough to not be driving performance.

Second, while I don't know of any recent research, I think [AP99] shows
that this is all a tradeoff and so one might want to be careful.  The
current algorithm (RFC 2988) does not often send spurious retransmits.
So, it stands to reason that when simply reducing the min and
calculating the time savings over the current min that things will in
fact be better.  I.e., you will not spend as much time waiting on
timeouts you need to take.  However, the flip side of the coin is that
by reducing the minimum you are also increasing the chances of the RTO
expiring needlessly.  I.e., if you had waited longer for the ACK then
you would not have needed the RTO at all.  The impact of this is harder
to gauge than simply computing the "wait time" because in this case the
cwnd will be needlessly collapsed to 1 segment and the connection will
have to build the window back up.

As an example, from the paper if you simply reduce the min from 1sec to
250msec (as close as we come to the 200msec you cite above) you see that
wait time is reduced by 36% and at the same time we experience 3.6 times
the number of spurious retransmits.

This is all a tradeoff it seems to me.  We could not find a magic 'sweet
spot' that seemed to be a win in terms of wait time and number of
spurious timeouts.

All that said, the data I am quoting is old.  Perhaps on modern networks
a smaller minimum would behave as 1sec did quite a while back.  I have
no idea.  I think it would be nice if someone did a study to find out.

I hope that helps in some way.

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/20070919/ae26b40e/attachment.bin
>From [email-masked]  Wed Sep 19 22:03:33 2007
From: [email-masked] (Mark Allman)
Date: Thu Sep 20 00:05:02 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Linux currently uses much higher precision timestamps than the old BSD
> implementations to which the RFC refers, so it shouldn't really be an
> issue.

I cannot follow this.  What is the "it" that shouldn't be an issue?

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/20070919/aac48ac5/attachment.bin
>From [email-masked]  Wed Sep 19 22:58:42 2007
From: [email-masked] (Sushant Rewaskar)
Date: Thu Sep 20 00:38:43 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Everyone,
	I recently conducted a detailed investigation of the very question
raised in this mail. This work is due to be presented at ICNP 2007. The
paper is located at  
http://www.cs.unc.edu/~rewaskar/publication/ICNP_07.pdf

Objective of this work was to (i) understand the performance of current TCP
deployments, (ii) evaluate different setting for TCP loss detection
mechanism's thresholds (i.e. the RTO and dupack parameter settings), and
(iii) identify the best parameters and calculate the impact of these
choices.

We passively analyze more than 2.8 million real world connections using a
very detailed passive analysis tool named TCPdebug (details at
http://www.cs.unc.edu/~rewaskar/publication/Pam_2006.pdf). For different
parameter settings, rather than simply studying the number of unneeded
retransmission and the saving in detection time, we developed analytical
models to estimate the actual impact in terms of change in connection
duration for a TCP connection.

Based on our experiments we have identified several changes to TCP like -
(i) dynamically adapt dupack threshold based on flight size, (ii) Reduce
minimum retransmission timeouts to 200ms or lower, (iii) make RTO more
aggressive by reducing contribution of RTT variation factor from 4 to 2.

Please feel free to contact us if you have any question on the method or our
findings (I am traveling for a better part of this month and so please
excuse any delay in my responses)

Take care,
Sushant Rewaskar
-----------------------------
UNC Chapel Hill
www.cs.unc.edu/~rewaskar 
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Allman
Sent: Wednesday, September 19, 2007 5:02 PM
To: Ian McDonald
Cc: [email-masked]
Subject: Re: [Iccrg] Question on RFC 2988 - TCP Retransmission timer

[I answered this on the TCPM list where Ian also posted it.  I am just
 now doing a little catchup on the ICCRG list and so I will replay my
 answer here.  --allman]

Ian-

> After some discussion on the Linux networking list I thought I'd ask
> the question here.
> 
> In RFC 2988 Section 2.4 says:
>   (2.4) Whenever RTO is computed, if it is less than 1 second then the
>         RTO SHOULD be rounded up to 1 second.
> 
>         Traditionally, TCP implementations use coarse grain clocks to
>         measure the RTT and trigger the RTO, which imposes a large
>         minimum value on the RTO.  Research suggests that a large
>         minimum RTO is needed to keep TCP conservative and avoid
>         spurious retransmissions [AP99].  Therefore, this
>         specification requires a large minimum RTO as a conservative
>         approach, while at the same time acknowledging that at some
>         future point, research may show that a smaller minimum RTO is
>         acceptable or superior.
> 
> Given that Linux, BSD etc use 200 milliseconds, not 1 second I am
> wondering whether there has in fact been any research done as
> mentioned in last sentence. 

I am not aware of any.

> It seems a very high timeout especially on two locally connected
> devices.

Well, a couple of things .... 

First, if the performance is driven by the magnitude of the RTO then
that is a more general problem than with the min RTO, I think.  We have
devised much better loss recovery than relying on the RTO and so one
would hope that RTOs are rare enough to not be driving performance.

Second, while I don't know of any recent research, I think [AP99] shows
that this is all a tradeoff and so one might want to be careful.  The
current algorithm (RFC 2988) does not often send spurious retransmits.
So, it stands to reason that when simply reducing the min and
calculating the time savings over the current min that things will in
fact be better.  I.e., you will not spend as much time waiting on
timeouts you need to take.  However, the flip side of the coin is that
by reducing the minimum you are also increasing the chances of the RTO
expiring needlessly.  I.e., if you had waited longer for the ACK then
you would not have needed the RTO at all.  The impact of this is harder
to gauge than simply computing the "wait time" because in this case the
cwnd will be needlessly collapsed to 1 segment and the connection will
have to build the window back up.

As an example, from the paper if you simply reduce the min from 1sec to
250msec (as close as we come to the 200msec you cite above) you see that
wait time is reduced by 36% and at the same time we experience 3.6 times
the number of spurious retransmits.

This is all a tradeoff it seems to me.  We could not find a magic 'sweet
spot' that seemed to be a win in terms of wait time and number of
spurious timeouts.

All that said, the data I am quoting is old.  Perhaps on modern networks
a smaller minimum would behave as 1sec did quite a while back.  I have
no idea.  I think it would be nice if someone did a study to find out.

I hope that helps in some way.

allman

From: [email-masked] (WangYaogong)
Date: Sun Sep 16 05:36:19 2007
Subject: [Iccrg] Fairness VS Friendliness
Message-ID: <[email-masked]>

Hi,
 
I'm somewhat confused about the similarities and differences between the concepts of fairness and friendliness. Sometimes they seem to be equivalent, but sometimes not. For example, a TCP-friendly protocol may not be fair to TCP in all conditions. It may occupy much more bandwidth than TCP in large BDP networks where TCP cannot make full use of the high speed.
 
According to my understanding, I define Fairness and Friendliness as follow:
 
Fairness: On a path with a single bottleneck, two competing long-lived flows with the same RTT should achieve approximately the same average throughput. We can use Jain's Index to measure it.
 
Friendliness:  A is said to be friendly to B if:
when coexisting with B, A will not decrease the speed of B in any setting ( i.e. B gets as much bandwidth competing against A as it would competing against with another B flow)
We may use the bandwidth stolen by A from B, divided by B's original bandwidth, to measure it.
 
Is my understanding correct? Thanks.
 
Yaogong
 
_________________________________________________________________
�� Live Search �Ѿ�������Ѷ��
http://www.live.com/?searchOnly=true
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070916/1ba5836b/attachment.html
>From [email-masked]  Mon Sep 17 15:07:34 2007
From: [email-masked] (Wesley Eddy)
Date: Mon Sep 17 17:08:36 2007
Subject: [Iccrg] RE: delay and gooput fairness
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thu, Sep 13, 2007 at 02:52:42PM -0700, Lachlan Andrew wrote:
> Greetigns C?sar,
> 
> For delay, you could use Jain's index. (I think he proposed it in the
> 1989 paper "Analysis of the increase and decrease algorithms for
> congestion avoidance in computer networks".  Could someone correct
> me?)
> 

It's very nicely explained in:
R. Jain, D. Chiu, and W. Hawe, "A Quantitative Measure Of Fairness And
Discrimination For Resource Allocation In Shared Computer Systems", DEC
Research Report TR-301, September 1984.

online at:
http://www.cse.wustl.edu/~jain/papers/fairness.htm

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Sally Floyd)
Date: Fri Sep 14 16:50:23 2007
Subject: [Iccrg] RE: delay and gooput fairness
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Cesar -

> Is there any measure of "delay fairness" or "goodput fairness" for a 
> group
> of TCP flows served by a FQ algorithm?

You could look at the TMRG document "Metrics for the Evaluation of
Congestion Control Mechanisms", available from the TMRG web
page at "http://www.icir.org/tmrg/", for pointers to some of the 
fairness
metrics that have been used in the past.

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

From: [email-masked] (Lachlan Andrew)
Date: Fri Sep 14 00:32:27 2007
Subject: [Iccrg] RE: delay and gooput fairness
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetigns C?sar,

For delay, you could use Jain's index. (I think he proposed it in the
1989 paper "Analysis of the increase and decrease algorithms for
congestion avoidance in computer networks".  Could someone correct
me?)

Jain's index is fairly poor for goodput, but you can use Jain's index
on the reciprocal of the goodput.

An alternative is to use Kelly's utility maximization framework, and
measure the drop in utility due to the inequality of rates.

Cheers,
Lachlan

On 13/09/2007, C?sar C?rdenas <[email-masked]> wrote:
> Dear all,
> I realize I made a wrong question:
>
> Is there any measure of "delay fairness" or "goodput fairness" for a group
> of TCP flows served by a FQ algorithm?
> If yes, do you know a procedure to estimate them when you have 30 replications?
> Or do you have some suggestions?
>
> Many thanks in advance,
> C?sar
>
> >-- Mensaje Original --
> >Date: Thu, 13 Sep 2007 18:41:22 +0200
> >From: C?sar C?rdenas <[email-masked]>
> >Subject: delay and gooput fairness
> >Reply-To: [email-masked]
> >To: [email-masked]
> >Cc: [email-masked]
> >
> >
> >Dear all,
> >
> >It there any measure for "delay fairness" or "goodput fairness" of a TCP
> >flow?
> >
> >If yes, I would appreciate if you point me to a good reference,
> >
> >I apologize if these both lists are not adequate for this question.
> >
> >Please accept my best regards,
> >C?sar
> >
> >
> >C?sar C?rdenas-P?rez ([email-masked])
> >Monterrey Tech, Quer?taro Campus, M?xico
> >http://www.qro.itesm.mx
> >Personal Phone: +(33) 633306689
> >Office Phone: +(33) 145817146
> >Office Fax: +(33) 145813119
> >Skype pseudo: cesarcardenas7
> >All phones and fax from abroad France
> >
> >The content of this data transmission is not considered as an offer, proposal,
> >understanding, or agreement unless it is confirmed in a document signed
> by
> >a legal representative of ITESM. The content of this data transmission is
> >confidential and it is intended to be delivered only to the addresses, therefore,
> >it shall not be distributed and/or disclosed through any mean without the
> >original sender's previous authorization. If you are not the addressee you
> >are forbidden to use it, either totally or partially, for any purpose.
> >
> >
>
> C?sar C?rdenas-P?rez ([email-masked])
> Monterrey Tech, Quer?taro Campus, M?xico
> http://www.qro.itesm.mx
> Personal Phone: +(33) 633306689
> Office Phone: +(33) 145817146
> Office Fax: +(33) 145813119
> Skype pseudo: cesarcardenas7
> All phones and fax from abroad France
>
> The content of this data transmission is not considered as an offer, proposal,
> understanding, or agreement unless it is confirmed in a document signed by
> a legal representative of ITESM. The content of this data transmission is
> confidential and it is intended to be delivered only to the addresses, therefore,
> it shall not be distributed and/or disclosed through any mean without the
> original sender's previous authorization. If you are not the addressee you
> are forbidden to use it, either totally or partially, for any purpose.
>
>
> _______________________________________________
> 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] (=?ISO-8859-15?Q?C=E9sar=20C=E1rdenas?=)
Date: Thu Sep 13 20:41:15 2007
Subject: [Iccrg] RE: delay and gooput fairness
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Dear all,
I realize I made a wrong question:

Is there any measure of "delay fairness" or "goodput fairness" for a group
of TCP flows served by a FQ algorithm?
If yes, do you know a procedure to estimate them when you have 30 replications?
Or do you have some suggestions?

Many thanks in advance,
C?sar

>-- Mensaje Original --
>Date: Thu, 13 Sep 2007 18:41:22 +0200
>From: C?sar C?rdenas <[email-masked]>
>Subject: delay and gooput fairness
>Reply-To: [email-masked]
>To: [email-masked]
>Cc: [email-masked]
>
>
>Dear all,
>
>It there any measure for "delay fairness" or "goodput fairness" of a TCP
>flow?
>
>If yes, I would appreciate if you point me to a good reference,
>
>I apologize if these both lists are not adequate for this question.
>
>Please accept my best regards,
>C?sar
>
>
>C?sar C?rdenas-P?rez ([email-masked])
>Monterrey Tech, Quer?taro Campus, M?xico
>http://www.qro.itesm.mx
>Personal Phone: +(33) 633306689
>Office Phone: +(33) 145817146
>Office Fax: +(33) 145813119
>Skype pseudo: cesarcardenas7
>All phones and fax from abroad France
>
>The content of this data transmission is not considered as an offer, proposal,
>understanding, or agreement unless it is confirmed in a document signed
by
>a legal representative of ITESM. The content of this data transmission is
>confidential and it is intended to be delivered only to the addresses, therefore,
>it shall not be distributed and/or disclosed through any mean without the
>original sender's previous authorization. If you are not the addressee you
>are forbidden to use it, either totally or partially, for any purpose.
>
>

C?sar C?rdenas-P?rez ([email-masked])
Monterrey Tech, Quer?taro Campus, M?xico
http://www.qro.itesm.mx
Personal Phone: +(33) 633306689
Office Phone: +(33) 145817146
Office Fax: +(33) 145813119
Skype pseudo: cesarcardenas7
All phones and fax from abroad France

The content of this data transmission is not considered as an offer, proposal,
understanding, or agreement unless it is confirmed in a document signed by
a legal representative of ITESM. The content of this data transmission is
confidential and it is intended to be delivered only to the addresses, therefore,
it shall not be distributed and/or disclosed through any mean without the
original sender's previous authorization. If you are not the addressee you
are forbidden to use it, either totally or partially, for any purpose.

From: [email-masked] (=?ISO-8859-15?Q?C=E9sar=20C=E1rdenas?=)
Date: Thu Sep 13 19:23:26 2007
Subject: [Iccrg] delay and gooput fairness
Message-ID: <[email-masked]>

Dear all,

It there any measure for "delay fairness" or "goodput fairness" of a TCP
flow?

If yes, I would appreciate if you point me to a good reference,

I apologize if these both lists are not adequate for this question.

Please accept my best regards,
C?sar

C?sar C?rdenas-P?rez ([email-masked])
Monterrey Tech, Quer?taro Campus, M?xico
http://www.qro.itesm.mx
Personal Phone: +(33) 633306689
Office Phone: +(33) 145817146
Office Fax: +(33) 145813119
Skype pseudo: cesarcardenas7
All phones and fax from abroad France

The content of this data transmission is not considered as an offer, proposal,
understanding, or agreement unless it is confirmed in a document signed by
a legal representative of ITESM. The content of this data transmission is
confidential and it is intended to be delivered only to the addresses, therefore,
it shall not be distributed and/or disclosed through any mean without the
original sender's previous authorization. If you are not the addressee you
are forbidden to use it, either totally or partially, for any purpose.

From: [email-masked] (Bob Briscoe)
Date: Fri Sep  7 14:37:17 2007
Subject: Congestion Notification from lower layers (was: Re: [Iccrg] update to cc-rfcs draft)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070907/14cba583/attachment.html
>From [email-masked]  Sat Sep  8 07:01:46 2007
From: [email-masked] (Lars Eggert)
Date: Sat Sep  8 08:43:16 2007
Subject: [Iccrg] Fwd: [e2e] Logging active TCP details in FreeBSD 5, 6 and 7
References: <[email-masked]>
Message-ID: <[email-masked]>

FYI

Begin forwarded message:
> From: "ext grenville armitage" <[email-masked]>
> Date: September 7, 2007 9:34:16 GMT+03:00
> To: end2end <[email-masked]>
> Subject: [e2e] Logging active TCP details in FreeBSD 5, 6 and 7
>
> All,
>
> On the off chance this is of general interest, I'd like to let
> people know of a FreeBSD kernel module we've developed for
> logging various TCP state variables in a running kernel
> while sessions are active.
>
> Called SIFTR ("sifter"), we built this for our own research into
> precisely how a FreeBSD TCP stack behaves when faced with real
> and artificial (e.g. dummynet) paths. Figured it might also be
> of interest to others.
>
> See http://caia.swin.edu.au/urp/newtcp/tools.html (under SIFTR)
> for a readme, changelog and tarball. The authors would love to get
> feedback from anyone trying it out. (SIFTR has been developed and
> tested mostly under FreeBSD 6.2, but we believe it'll be stable
> under 5.x and 7.x too.)
>
> cheers,
> gja
>

-------------- 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/20070908/f25e10db/smime.bin
>From [email-masked]  Mon Sep 10 00:01:39 2007
From: [email-masked] ([email-masked])
Date: Mon Sep 10 01:54:09 2007
Subject: [Iccrg] Congestion control train-wreck workshop at Stanford: Call
	for Demos
Message-ID: <[email-masked]>

Congestion control train-wreck workshop at Stanford: Call for Demos

We would like to invite you to a two-day congestion control workshop,  
titled "Train-wrecks and congestion control: What happens if we do  
nothing?", which we are hosting at Stanford on 31 March - 1 April, 2008.

Spurred on by a widespread belief that TCP is showing its age and  
needs replacing - and a deeper understanding of the dynamics of  
congestion control - the research community has brought forward many  
new congestion control algorithms. There has been lots of debate about  
the relative merits and demerits of the new schemes; and a  
standardization effort is under way in the IETF.

But before the next congestion control mechanism is deployed, it will  
need to be deployed widely in operating systems and - in some cases -  
in switches and routers too. This will be a long road, requiring the  
buy-in of many people: Researchers, product developers and business  
leaders too. Our own experience of proposing new congestion control  
algorithms has been met with the challenge: "Show me the compelling  
need for a new congestion control mechanisms?", and "What will really  
happen to the Internet (and my business) if we keep TCP just the way  
it is?"

As a community, we need examples that are simple to understand, and  
demonstrate a compelling need for change. We call them the "Train  
wreck scenarios". Examples might show that distribution of video over  
wireless in the home will come to a halt without new algorithms. Or  
that P2P traffic will bring the whole network crashing down. Or that  
huge, high-performance data-centers need new algorithms. Whatever your  
favorite example, we believe that if we are collectively armed with a  
handful of mutually agreed examples, it will be much easier to make a  
business case for change. Or put another way, if we can't articulate  
compelling examples to industry leaders, then is the cost and risk of  
change worth it?

The goal of the workshop is to identify a handful of really compelling  
demonstrations of the impending train-wreck. The outcome will be a set  
of canonical examples that we will use to persuade industry of the  
need for change.

We are deliberately inviting you many months ahead of time - to give  
you time to create your compelling train-wreck demonstration. You can  
choose the way you present your demonstration: You could bring  
equipment and show a live-demo; you could show simulations or  
animations; or you could produce a video showing a real or synthetic  
demo. Whatever method you choose, the goal is to create a case that  
will persuade a mildly-technical but influential business leader of  
the need for change.

We will invite a panel of judges to give prizes for the most  
compelling examples in two categories: (1) The Overall Most Compelling  
Example, which will be judged on a combination of the technical merits  
and the presentation of the scenario, and (2) The Most Technically  
Compelling Example, which will be judged on its technical merit alone,  
without consideration of the way it is presented.

The whole purpose of the workshop it to focus on the {\em problem},  
not the solutions. We are most definitely {\em not} interested in your  
favorite scheme, or ours. So we need some ground-rules.
\begin{center}
{\em No-one is allowed to mention a specific mechanism, algorithm or  
proposal at any time during the workshop: Not in their talk, not in a  
panel, and not in questions to the speakers. The only mechanisms that  
will be allowed mention are: TCP (in its standard and deployed  
flavors), and idealized alternatives for purposes of demonstration.  
For example, comparing TCP with an oracle that provides instantaneous  
optimal rates to each flow.}
\end{center}

Attendance to the workshop will be by invitation only - to keep the  
discussion focused and lively.  We will video the entire workshop and  
all the demonstrations, and make it publicly available on the  
Internet. We will make any proceedings and talks available too. The  
goal is to open up the demonstrations for public scrutiny and feedback  
after the event.

The event is hosted by the Stanford Clean Slate Program -  
http://cleanslate.stanford.edu - and local arrangements will be made  
by Nick McKeown and Nandita Dukkipati. The workshop has received  
offers of support and funding from Cisco Systems and Microsoft. We  
hope to make a limited number of travel grants available.

We have a small Program Committee (listed below) to select the final  
demonstrations. We are soliciting a 1-page description of your demo.  
Please note the following dates.

Important Dates:
===============
Workshop: 31 March - 1 April, 2008
1-page demo description submission deadline: 1 Dec, 2007
Notification of acceptance: 15 Dec, 2007
Final demo submissions: 17 March, 2008
Last date for demo withdrawals: 25 March, 2008

Please email your initial 1-page submissions to:
Nandita Dukkipati <[email-masked]> and
Nick McKeown <[email-masked]>

Best wishes, and we hope to see you in Stanford!

Nandita Dukkipati
Nick McKeown

Program Committee:
==================
1. Albert Greenberg, Microsoft Research
2. Peter Key, Microsoft Research
3. Flavio Bonomi, Cisco
4. Bruce Davie, Cisco
5. Steven Low, Caltech
6. Frank Kelly, Cambridge
7. Lars Eggert, Nokia Research/IETF
8. Nick McKeown, Stanford
9. Guru Parulkar, Stanford
10. Nandita Dukkipati, Stanford/Cisco/Princeton

From: [email-masked] (Dirceu Cavendish)
Date: Thu Sep  6 21:04:33 2007
Subject: [Iccrg] update to cc-rfcs draft
Message-ID: <[email-masked]>

Wesley,

About the last paragraph discussed, I dont know how much you want to dwelve into L2 considerations in the document. However, there are two initiatives within IEEE 802 standards about congestion control in Ethernets: 802.1au congestion notification (http://www.ieee802.org/1/pages/802.1au.html ), and 802.3ar congestion management (http://www.ieee802.org/3/ar/index.html ). I can provide some level of detail about the creation and intent of these groups, if needed, as I was somehow involved with them up to late last year.

Rgds,
Dirceu
PS: Could you kindly add [email-masked] to iccrg mailing list?

----- Original Message ----
From: Wesley Eddy <[email-masked]>
To: Bob Briscoe <[email-masked]>
Cc: [email-masked]
Sent: Thursday, September 6, 2007 7:57:57 AM
Subject: Re: [Iccrg] update to cc-rfcs draft

On Thu, Sep 06, 2007 at 02:55:10PM +0100, Bob Briscoe wrote:
> Wes,
> 
> I'd just like to say I found the previous version of this draft extremely 
> useful - it is rare to have such a resource to ensure people don't forget 
> how much has already been done.
> 
> Below are a couple of comments on the wording of the justification for why 
> the scope avoids QoS & MAC (in 1. Introduction). I agree your scoping is 
> reasonable, I'm just saying it's been justified and described in a way that 
> I don't think is fitting...
>
> ...
>
> So this para really needs re-writing to say QoS is out of scope whether at 
> L3 or L2, but L2 notifying the endpoints using losses or ECN is in scope. 
> Obviously there will only be RFCs about specific link technologies if the 
> IETF is responsible for standardising that L2 technology (e.g. MPLS), but 
> as you've pointed out, there are RFCs giving design advice for how link 
> layers in general should interwork with congestion control (e.g. all the 
> PILC stuff you mention).
> 

Thanks; those comments do help.  I'll suggest the text below as a fix, and
appreciate if you can tweak anything that's still wrong with it :).

Change this old incorrect text:

- We specifically do not include the vast amount of QoS work
- into the scope of this document, as it is a full field in its own
- right, and deals with issues that are mostly orthogonal to end-host
- congestion control and router queue management.  Although there can
- certainly be interactions between QoS and congestion control
- mechanisms, scheduling mechanisms used to implement QoS (on either
- per-flow or an aggregate basis), for instance, can be used
- independently of the end-host congestion control and queue management
- functions also in use.  Similar arguments can be made for traffic-
- shaping, admission control, and other functions that are intended for
- QoS, and only side-notes for congestion control.

into:

+ We specifically do not include the vast amount of QoS work
+ into the scope of this document, as it is a full field in its own
+ right.  Some "open-loop" QoS mechanisms that do not involve
+ signalling (e.g. classic DiffServ) can be used independently of
+ specific queue management algorithms and end-host congestion control
+ mechanisms.  Closed-loop mechanisms designed for applications with
+ less-elastic packet-sending rates that operate at per-flow granularity
+ are out of scope for this document, which focuses on packet-level
+ congestion control.  Some recent work has proposed re-use of existing
+ congestion control protocols for elastic applications in order to
+ support edge-to-edge admission control for inelastic applications
+ [PCN-ARCH], however, no RFCs have yet been published on this work.

and this old incorrect text:

- A similar argument can be made for excluding consideration of the
- media access control (MAC) layer protocols used by the links
- throughout a path.  Although the MAC protocols implement various
- forms of resolving contention for shared links (and sometimes offer
- QoS services), these are also distinct from end-to-end congestion
- control.  Furthermore, MAC protocols are not typically discussed in
- the RFC series, but are defined in outside documents (e.g.  IEEE
- standards), since the IETF does not generally work on link layers
- themselves.  Few, if any, of the RFCs that describe mappings of IP
- onto various link layers directly discuss congestion control.

into:

+ Since link layers have their own queues in addition to IP layer queues,
+ congestion can manifest itself at the link layer, below the radar of
+ IP-layer congestion detection and marking mechanisms.  Few, if any, of
+ the RFCs that describe mappings of IP onto various link layers directly
+ discuss congestion control, and we consider them out of scope for this
+ document's purposes.  Current IETF work invoves use of IP-layer
+ congestion notification for packets forwarded within MPLS [ECN-MPLS],
+ which operates as a shim between the link and network layers.  Several
+ of the RFCs discussed in Section 4 of this document discuss how general
+ classes of link layers interact with congestion control.  Since link
+ layer specifications are usually the product of bodies outside the IETF
+ (e.g. the IEEE standards), tighter integration of congestion control with
+ link layer technologies is a mostly open area.

Please let me know if these can be improved; I won't be insulted at all
if the paragraphs have to be redone from scratch.  As long as we still
agree to not burden ourselves with QoS RFCs, I'll be happy!

It's probably off-topic for this RG, but I think someone should make up
a similar "reader's guide"/"RFC roadmap"/"annotated bibliography" or
whatever you want to call it for all the QoS RFCs ...

-- 
Wesley M. Eddy
Verizon Federal Network Systems

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

       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070906/ab1aec19/attachment-0001.html
>From [email-masked]  Fri Sep  7 12:34:37 2007
From: [email-masked] (Bob Briscoe)
Date: Fri Sep  7 14:14:09 2007
Subject: [Iccrg] update to cc-rfcs draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Wes,

These look much better now. See inline for nits...

At 15:57 06/09/2007, Wesley Eddy wrote:
>On Thu, Sep 06, 2007 at 02:55:10PM +0100, Bob Briscoe wrote:
> > Wes,
> >
> > I'd just like to say I found the previous version of this draft extremely
> > useful - it is rare to have such a resource to ensure people don't forget
> > how much has already been done.
> >
> > Below are a couple of comments on the wording of the justification for why
> > the scope avoids QoS & MAC (in 1. Introduction). I agree your scoping is
> > reasonable, I'm just saying it's been justified and described in a way 
> that
> > I don't think is fitting...
> >
> > ...
> >
> > So this para really needs re-writing to say QoS is out of scope whether at
> > L3 or L2, but L2 notifying the endpoints using losses or ECN is in scope.
> > Obviously there will only be RFCs about specific link technologies if the
> > IETF is responsible for standardising that L2 technology (e.g. MPLS), but
> > as you've pointed out, there are RFCs giving design advice for how link
> > layers in general should interwork with congestion control (e.g. all the
> > PILC stuff you mention).
> >
>
>
>Thanks; those comments do help.  I'll suggest the text below as a fix, and
>appreciate if you can tweak anything that's still wrong with it :).
>
>Change this old incorrect text:
>
>- We specifically do not include the vast amount of QoS work
>- into the scope of this document, as it is a full field in its own
>- right, and deals with issues that are mostly orthogonal to end-host
>- congestion control and router queue management.  Although there can
>- certainly be interactions between QoS and congestion control
>- mechanisms, scheduling mechanisms used to implement QoS (on either
>- per-flow or an aggregate basis), for instance, can be used
>- independently of the end-host congestion control and queue management
>- functions also in use.  Similar arguments can be made for traffic-
>- shaping, admission control, and other functions that are intended for
>- QoS, and only side-notes for congestion control.
>
>into:
>
>+ We specifically do not include the vast amount of QoS work
>+ into the scope of this document, as it is a full field in its own
>+ right.  Some "open-loop" QoS mechanisms that do not involve
>+ signalling (e.g. classic DiffServ) can be used independently of
>+ specific queue management algorithms

I know what you meant, but the phrase "queue management algorithms" 
includes scheduling, which is very much in Diffserv land. How about 
replacing it with "load management algorithms"?

>and end-host congestion control
>+ mechanisms.  Closed-loop mechanisms designed for applications with
>+ less-elastic packet-sending rates that operate at per-flow granularity
>+ are out of scope for this document, which focuses on packet-level
>+ congestion control.  Some recent work has proposed re-use of existing
>+ congestion control protocols for elastic applications in order to
>+ support edge-to-edge admission control for inelastic applications
>+ [PCN-ARCH], however, no RFCs have yet been published on this work.
>
>and this old incorrect text:
>
>- A similar argument can be made for excluding consideration of the
>- media access control (MAC) layer protocols used by the links
>- throughout a path.  Although the MAC protocols implement various
>- forms of resolving contention for shared links (and sometimes offer
>- QoS services), these are also distinct from end-to-end congestion
>- control.  Furthermore, MAC protocols are not typically discussed in
>- the RFC series, but are defined in outside documents (e.g.  IEEE
>- standards), since the IETF does not generally work on link layers
>- themselves.  Few, if any, of the RFCs that describe mappings of IP
>- onto various link layers directly discuss congestion control.
>
>into:
>
>+ Since link layers have their own queues in addition to IP layer queues,
>+ congestion can manifest itself at the link layer, below the radar of
>+ IP-layer congestion detection and marking mechanisms.  Few, if any, of
>+ the RFCs that describe mappings of IP onto various link layers directly
>+ discuss congestion control, and we consider them out of scope for this
>+ document's purposes.

Just to be picky, I would suggest removing "if any" and the last clause 
after comma.
- "If any" isn't nec. because in the next sentence you mention one - MPLS.
- And if there were any in the IETF as opposed to IEEE, there would be no 
reason for them not to be in scope.
This leaves the sentence as:

"Few of the RFCs that describe mappings of IP onto various link layers 
directly discuss congestion control."

>Current IETF work invoves

Typo: involves

>use of IP-layer
>+ congestion notification for packets forwarded within MPLS [ECN-MPLS],
>+ which operates as a shim between the link and network layers.  Several
>+ of the RFCs discussed in Section 4 of this document discuss how general
>+ classes of link layers interact with congestion control.  Since link
>+ layer specifications are usually the product of bodies outside the IETF
>+ (e.g. the IEEE standards), tighter integration of congestion control with
>+ link layer technologies is a mostly open area.
>
>
>Please let me know if these can be improved; I won't be insulted at all
>if the paragraphs have to be redone from scratch.  As long as we still
>agree to not burden ourselves with QoS RFCs, I'll be happy!

They're fine as they stand, even if you don't want to take on my comments. 
Thanks

Bob

>It's probably off-topic for this RG, but I think someone should make up
>a similar "reader's guide"/"RFC roadmap"/"annotated bibliography" or
>whatever you want to call it for all the QoS RFCs ...
>
>--
>Wesley M. Eddy
>Verizon Federal Network Systems

____________________________________________________________________________
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] (Wesley Eddy)
Date: Thu Sep  6 17:42:20 2007
Subject: [Iccrg] update to cc-rfcs draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Sep 06, 2007 at 02:55:10PM +0100, Bob Briscoe wrote:
> Wes,
> 
> I'd just like to say I found the previous version of this draft extremely 
> useful - it is rare to have such a resource to ensure people don't forget 
> how much has already been done.
> 
> Below are a couple of comments on the wording of the justification for why 
> the scope avoids QoS & MAC (in 1. Introduction). I agree your scoping is 
> reasonable, I'm just saying it's been justified and described in a way that 
> I don't think is fitting...
>
> ...
>
> So this para really needs re-writing to say QoS is out of scope whether at 
> L3 or L2, but L2 notifying the endpoints using losses or ECN is in scope. 
> Obviously there will only be RFCs about specific link technologies if the 
> IETF is responsible for standardising that L2 technology (e.g. MPLS), but 
> as you've pointed out, there are RFCs giving design advice for how link 
> layers in general should interwork with congestion control (e.g. all the 
> PILC stuff you mention).
> 

Thanks; those comments do help.  I'll suggest the text below as a fix, and
appreciate if you can tweak anything that's still wrong with it :).

Change this old incorrect text:

- We specifically do not include the vast amount of QoS work
- into the scope of this document, as it is a full field in its own
- right, and deals with issues that are mostly orthogonal to end-host
- congestion control and router queue management.  Although there can
- certainly be interactions between QoS and congestion control
- mechanisms, scheduling mechanisms used to implement QoS (on either
- per-flow or an aggregate basis), for instance, can be used
- independently of the end-host congestion control and queue management
- functions also in use.  Similar arguments can be made for traffic-
- shaping, admission control, and other functions that are intended for
- QoS, and only side-notes for congestion control.

into:

+ We specifically do not include the vast amount of QoS work
+ into the scope of this document, as it is a full field in its own
+ right.  Some "open-loop" QoS mechanisms that do not involve
+ signalling (e.g. classic DiffServ) can be used independently of
+ specific queue management algorithms and end-host congestion control
+ mechanisms.  Closed-loop mechanisms designed for applications with
+ less-elastic packet-sending rates that operate at per-flow granularity
+ are out of scope for this document, which focuses on packet-level
+ congestion control.  Some recent work has proposed re-use of existing
+ congestion control protocols for elastic applications in order to
+ support edge-to-edge admission control for inelastic applications
+ [PCN-ARCH], however, no RFCs have yet been published on this work.

and this old incorrect text:

- A similar argument can be made for excluding consideration of the
- media access control (MAC) layer protocols used by the links
- throughout a path.  Although the MAC protocols implement various
- forms of resolving contention for shared links (and sometimes offer
- QoS services), these are also distinct from end-to-end congestion
- control.  Furthermore, MAC protocols are not typically discussed in
- the RFC series, but are defined in outside documents (e.g.  IEEE
- standards), since the IETF does not generally work on link layers
- themselves.  Few, if any, of the RFCs that describe mappings of IP
- onto various link layers directly discuss congestion control.

into:

+ Since link layers have their own queues in addition to IP layer queues,
+ congestion can manifest itself at the link layer, below the radar of
+ IP-layer congestion detection and marking mechanisms.  Few, if any, of
+ the RFCs that describe mappings of IP onto various link layers directly
+ discuss congestion control, and we consider them out of scope for this
+ document's purposes.  Current IETF work invoves use of IP-layer
+ congestion notification for packets forwarded within MPLS [ECN-MPLS],
+ which operates as a shim between the link and network layers.  Several
+ of the RFCs discussed in Section 4 of this document discuss how general
+ classes of link layers interact with congestion control.  Since link
+ layer specifications are usually the product of bodies outside the IETF
+ (e.g. the IEEE standards), tighter integration of congestion control with
+ link layer technologies is a mostly open area.

Please let me know if these can be improved; I won't be insulted at all
if the paragraphs have to be redone from scratch.  As long as we still
agree to not burden ourselves with QoS RFCs, I'll be happy!

It's probably off-topic for this RG, but I think someone should make up
a similar "reader's guide"/"RFC roadmap"/"annotated bibliography" or
whatever you want to call it for all the QoS RFCs ...

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Bob Briscoe)
Date: Thu Sep  6 16:35:20 2007
Subject: [Iccrg] update to cc-rfcs draft
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Wes,

I'd just like to say I found the previous version of this draft extremely 
useful - it is rare to have such a resource to ensure people don't forget 
how much has already been done.

Below are a couple of comments on the wording of the justification for why 
the scope avoids QoS & MAC (in 1. Introduction). I agree your scoping is 
reasonable, I'm just saying it's been justified and described in a way that 
I don't think is fitting...

==========================================================================
"...

                            Similar arguments can be made for traffic-
    shaping, admission control, and other functions that are intended for
    QoS, and only side-notes for congestion control.

"

Even if you don't want to include all the QoS RFCs (which I think is a 
reasonable scoping decision) I don't think you should try to make out the 
distinction between QoS and congestion control is so clear-cut.

I suggest a distinction needs to be made between closed loop QoS (which is 
surely NOT a side-note to congestion control) and open loop QoS (which is 
built completely differently to congestion control).

Open loop QoS through provisioning (like classic Diffserv) is clearly easy 
to separate off as a distinct field.
But admission control is closed loop (through the signalling protocol) and 
directly notifies congestion at short time scales on each queue to the 
application (ie admission is denied when resources would otherwise be 
exhausted - congestion). So strictly, this draft should say its scope is 
congestion control SOLELY for elastic apps (at packet granularity), and 
congestion control for inelastic apps at flow granularity is out of scope.

This suggests even the title might need clarifying.

You only have to look at the pre-congestion notification (PCN) w-g to see 
how congestion control protocols designed for elastic apps (ECN) can be 
re-used edge-edge to create an admission control behaviour for inelastic 
apps. If you wanted to point to this similarity, you could refer to the the 
first w-g I-D on its architecture that was published 3wks ago:
         draft-ietf-pcn-architecture-00.txt.
See <http://tools.ietf.org/wg/pcn/> for more.

"

    A similar argument can be made for excluding consideration of the
    media access control (MAC) layer protocols used by the links
    throughout a path.  Although the MAC protocols implement various
    forms of resolving contention for shared links (and sometimes offer
    QoS services), these are also distinct from end-to-end congestion
    control.  Furthermore, MAC protocols are not typically discussed in
    the RFC series, but are defined in outside documents (e.g.  IEEE
    standards), since the IETF does not generally work on link layers
    themselves.  Few, if any, of the RFCs that describe mappings of IP
    onto various link layers directly discuss congestion control.

"
Certainly I agree QoS in the MAC layer whould be out of scope for the same 
reasons it should be at the network layer...

But, as Tim Shepperd (correctly) argued at the last ICCRG mtg, congestion 
can cause losses in queues at any layer. Also AQM like RED is just as 
useful and possibly just as common in lower layer queues as in IP queues. 
And not just AQM for drop. AQM with ECN is relevant in lower layers where a 
network can be built.

Which brings me on to exceptions to the rule that the MAC layer isn't 
discussed at IETF. For instance the tsvwg has just requested publication of 
ECN in MPLS as a proposed standard: 
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-mpls-01.txt>.

So this para really needs re-writing to say QoS is out of scope whether at 
L3 or L2, but L2 notifying the endpoints using losses or ECN is in scope. 
Obviously there will only be RFCs about specific link technologies if the 
IETF is responsible for standardising that L2 technology (e.g. MPLS), but 
as you've pointed out, there are RFCs giving design advice for how link 
layers in general should interwork with congestion control (e.g. all the 
PILC stuff you mention).

HTH

Bob

At 15:18 27/08/2007, Wesley Eddy wrote:
>Michael and I completed an update of the cc-rfcs document that surveys
>the published RFCs dealing with congestion control:
>
>http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-02.txt
>
>Most of the changes come from the detailed review that Gorry sent us,
>along with some other comments from Sally Floyd, Mark Allman, Stephen
>Farrell, and Lars Eggert.  We also added a few more RFCs to the list.
>
>We realize that since RFC 5033 was *just* published, we need to add
>this to the draft, but aside from this, we'd also like to know if
>the update suffices to address people's comments.  A colorized rfcdiff
>is available for efficient checking:
>
>http://roland.grc.nasa.gov/~weddy/shared/iccrg/cc-rfcs-01-to-02-diff.html
>
>If possible, we'd like to finish revision of this within the RG by the
>end of September and move it forward.  Thanks for your comments and
>reviews :).
>
>--
>Wesley M. Eddy
>Verizon Federal Network Systems
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
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] (Michael Welzl)
Date: Tue Sep  4 14:28:32 2007
Subject: [Iccrg] Experimental congestion control proposal evaluation procedure
Message-ID: <[email-masked]>

Dear all,

We found that, by only following the procedure in
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt
but no further rules, it is not ensured that everyone is
in the loop as drafts are submitted to us for evaluation.

We therefore follow the below procedure from now on (i.e.
this doesn't affect the two proposals that we already
have on our table - btw, we're still hoping to get
volunteers for evaluating CUBIC!). This procedure is
now also on the ICCRG web site.

Cheers,
Michael

---

(1) The authors submit an independent I-D.

(2) The authors explicitly tell the TCPM WG and the TCPM co-chairs [*]
        that they'd like their I-D to become a work item and eventually
        an experimental RFC. 
        
        [*] Could perhaps be TSVWG if this is not a TCP scheme (e.g.,
        XCP).

(3) The TCPM co-chairs send an email to the ICCRG co-chairs requesting
        that the ICCRG perform a safety review of the document.

(4) The ICCRG chairs mobilize the RG in whatever way they deem useful,
        get the reviews and return them to TCPM at the end of some
        review period.