Subject: [Iccrg] Incentives for ECN
From: [email-masked] (Dirceu Cavendish)
Date: Sun Jul 17 15:59:20 2011

Yes, that is exactly what I mean (quote):
"it would be sensible to allow a CA designer to specify a milder form of
back-off when ECN is received?  If so, I entirely agree."

Dirceu

________________________________
From: Lachlan Andrew <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; iccrg list 
<[email-masked]>
Sent: Fri, July 15, 2011 7:49:22 PM
Subject: Re: [Iccrg] Incentives for ECN

Greetings Dirceu,

On 16 July 2011 04:13, Dirceu Cavendish <[email-masked]> wrote:
> I know of base stations that drop IP packets in advance as a way to quench
> Internet side incoming (download) traffic
> This type of use case could be an incentive for operators to use ECN,
> without throwing away application data.

Yes, that is the incentive mentioned in the draft.  However, unless
loss rates are unacceptably high (>>1%, which causes CWND < 10
packets), then the amount of application data that gets lost is not
enough of an incentive.  (If it were, then ECN would already be widely
deployed.)

> And BTW, imho, ECNs being treated as loss at end-points may present a
> dis-incentive for end-points to react to ECNs at all, since the CA designer
> may find cwnd exponential decrease too drastic a measure to be taken when
> receiving ECNs.

I'm not sure that I understand this.  If ECNs are treated as loss at
end-points, then they are reacted to.  Do you mean that you think it
would be sensible to allow a CA designer to specify a milder form of
back-off when ECN is received?  If so, I entirely agree.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110717/24013eb2/attachment.html

From: [email-masked] (John Leslie)
Date: Sat Jul 16 14:08:18 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20110716130820.GE32499@verdi>

Lachlan Andrew <[email-masked]> wrote:
> On 16 July 2011 04:13, Dirceu Cavendish <[email-masked]> wrote:
> 
>> And BTW, imho, ECNs being treated as loss at end-points may present a
>> dis-incentive for end-points to react to ECNs at all, since the CA designer
>> may find cwnd exponential decrease too drastic a measure to be taken when
>> receiving ECNs.
> 
> I'm not sure that I understand this.  If ECNs are treated as loss at
> end-points, then they are reacted to.  Do you mean that you think it
> would be sensible to allow a CA designer to specify a milder form of
> back-off when ECN is received?  If so, I entirely agree.

   (In case I wasn't clear enough, I was suggesting research using the
"same" backoff but a quicker recovery.)

--
John Leslie <[email-masked]>

From: [email-masked] (Qazi, Ihsan Ayyub)
Date: Sat Jul 16 08:53:37 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]>
Message-ID: <[email-masked]>

I agree with the points Lachlan made. I think it is useful to ask: "What is an acceptable response to ECN when competing with flows that respond to loss?" I think new protocols should at least not starve flows responding to loss. Beyond that, there needs to be more deliberation within the community about how aggressive a response is okay.

regards,
Ihsan

Ihsan Ayyub Qazi
Postdoctoral Research Fellow
Centre for Advanced Internet Architectures (CAIA)
Melbourne, Australia
http://caia.swin.edu.au/cv/iqazi/
______________________________
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lachlan Andrew [[email-masked]]
Sent: Friday, July 15, 2011 5:00 AM
To: iccrg
Subject: [Iccrg] Incentives for ECN

Greetings all,

There was some discussion on LEDBAT recently about how to motivate
users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
suggested may be better followed up in ICCRG.

My understanding is that it is "essentially" impossible to give an
incentive if we follow the letter of RFC3168, which says ECN must be
treated "essentially" identically to loss.  That requirement was
written in the days when "TCP friendliness" was seen as essential.
These days, there are many proposals that do not aim for TCP
friendliness (either being less aggressive like LEDBAT, or more
aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time to
revisit the requirement that ECN be treated the same as loss.

People may argue that if one flow backs off less because it is
receiving ECN instead of loss, then this is "unfair" to the one
experiencing loss.  I would argue that "fair" = "no incentive".

I would propose that the ICCRG assess any new congestion control
algorithm (for "safety", "fairness" or whatever) on the assumption
that the flow may receive either ECN or loss while competing flows
receive loss.  If this gives acceptable performance, then there is no
need to require equal treatment of ECN and loss.

Of course, any such algorithm is not RFC3168 *compliant*, but it can
still be RFC3168 *compatible*.

Thoughts?

Lachlan

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

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

From: [email-masked] (Lachlan Andrew)
Date: Sat Jul 16 03:49:29 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu,

On 16 July 2011 04:13, Dirceu Cavendish <[email-masked]> wrote:
> I know of base stations that drop IP packets in advance as a way to quench
> Internet side incoming (download) traffic
> This type of use case could be an incentive for operators to use ECN,
> without throwing away application data.

Yes, that is the incentive mentioned in the draft.  However, unless
loss rates are unacceptably high (>>1%, which causes CWND < 10
packets), then the amount of application data that gets lost is not
enough of an incentive.  (If it were, then ECN would already be widely
deployed.)

> And BTW, imho, ECNs being treated as loss at end-points may present a
> dis-incentive for end-points to react to ECNs at all, since the CA designer
> may find cwnd exponential decrease too drastic a measure to be taken when
> receiving ECNs.

I'm not sure that I understand this.  If ECNs are treated as loss at
end-points, then they are reacted to.  Do you mean that you think it
would be sensible to allow a CA designer to specify a milder form of
back-off when ECN is received?  If so, I entirely agree.

Cheers,
Lachlan

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

From: [email-masked] (Dirceu Cavendish)
Date: Fri Jul 15 19:13:29 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I know of base stations that drop IP packets in advance as a way to quench 
Internet side incoming (download) traffic
This type of use case could be an incentive for operators to use ECN, without 
throwing away application data.

And BTW, imho, ECNs being treated as loss at end-points may present a 
dis-incentive for end-points to react to ECNs at all, since the CA designer may 
find cwnd exponential decrease too drastic a measure to be taken when receiving 
ECNs.

Dirceu

________________________________
From: ken carlberg <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: iccrg list <[email-masked]>
Sent: Fri, July 15, 2011 6:43:44 AM
Subject: Re: [Iccrg] Incentives for ECN

sorry, I probably wasn't clear enough in my response.  I agree that it would be 
helpful to add incentives for end-host support of ECN.  And I find what Lachlan 
has proposed as interesting, though it would be nice to see a more extensive 
description of the ideas.  And perhaps in following John's point of how this 
could be done, perhaps an experimental draft-rfc could be written in order for 
the wider community to comment on.

However, the end-point part of the ECN model is only one part of the picture of 
where we need more deployed support.  A while back, one of my interns did some 
testing and found that a number of ISPs zero out the ECN field in IP packets, 
thereby nulling any potential ECN support for end-to-end paths transiting that 
ISP.  And this needs to be addressed regardless of what ever additional end-host 
support is used to encourage the use of ECN.

-ken

On Jul 15, 2011, at 9:17 AM, Michael Welzl wrote:

> ... but from an endpoint's perspective, relying on ECN in addition to loss is 
>then no worse than relying on loss alone.
> 
> So this doesn't seem to be a reason for an endpoint not to use ECN as 
>Lachlan/Jana suggested.
> 
> Cheers,
> Michael
> 
> 
> On Jul 15, 2011, at 3:00 PM, ken carlberg wrote:
> 
>> There is also the issue of some ISPs zero'ing out the entire old ToS byte 
>>instead of only the diff-serv code points.  CONEX is one indirect incentive to 
>>change this practice so as to not touch the ECN bits in the IP header, but I 
>>think a stronger incentive is needed.  The only thing that comes to mind is 
>>non-technical -- simply putting up a wiki page that identifies the ISPs that 
>>zero out the ECN bits and hope that they can be nudged (shamed?) into changing 
>>their practices.
>> 
>> -ken
>> 
>> 
>> On Jul 15, 2011, at 8:27 AM, John Leslie wrote:
>> 
>>> Lachlan Andrew <[email-masked]> wrote:
>>>> 
>>>> There was some discussion on LEDBAT recently about how to motivate
>>>> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
>>>> suggested may be better followed up in ICCRG.
>>> 
>>> True...
>>> 
>>>> My understanding is that it is "essentially" impossible to give an
>>>> incentive if we follow the letter of RFC3168, which says ECN must be
>>>> treated "essentially" identically to loss.
>>> 
>>> That requirement has proven less than helpful.
>>> 
>>>> That requirement was written in the days when "TCP friendliness" was
>>>> seen as essential. These days, there are many proposals that do not
>>>> aim for TCP friendliness (either being less aggressive like LEDBAT,
>>>> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
>>>> to revisit the requirement that ECN be treated the same as loss.
>>> 
>>> I thoroughly agree -- but _how_ do we revisit it?
>>> 
>>> As a research question, that's entirely appropriate for ICCRG.
>>> 
>>>> People may argue that if one flow backs off less because it is
>>>> receiving ECN instead of loss, then this is "unfair" to the one
>>>> experiencing loss.  I would argue that "fair" = "no incentive".
>>> 
>>> I always argue that "fair" is one grade below "good" ;^)
>>> 
>>> But I must agree "fair" and "incentive" are often mutually
>>> exclusive. :^(
>>> 
>>>> I would propose that the ICCRG assess any new congestion control
>>>> algorithm (for "safety", "fairness" or whatever) on the assumption
>>>> that the flow may receive either ECN or loss while competing flows
>>>> receive loss.  If this gives acceptable performance, then there is no
>>>> need to require equal treatment of ECN and loss.
>>> 
>>> Interesting...
>>> 
>>> I would suggest that the essential feature of ECN is that it delivers
>>> a congestion signal _sooner_ -- so a CC algorithm which _initially_
>>> backs off more quickly upon receipt of an ECN mark, but after a few RTTs
>>> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
>>> a concept worth research.
>>> 
>>>> Of course, any such algorithm is not RFC3168 *compliant*, but it can
>>>> still be RFC3168 *compatible*.
>>> 
>>> :^)
>>> 
>>> --
>>> John Leslie <[email-masked]>
>>> 
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> 
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110715/70a9a245/attachment.html
>From [email-masked]  Sat Jul 16 03:43:54 2011
From: [email-masked] (Lachlan Andrew)
Date: Sat Jul 16 03:43:57 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <20110715122756.GC32499@verdi>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]>
	<20110715122756.GC32499@verdi>
Message-ID: <[email-masked]>

Greetings John,

On 15 July 2011 22:27, John Leslie <[email-masked]> wrote:
>
> ? I would suggest that the essential feature of ECN is that it delivers
> a congestion signal _sooner_ -- so a CC algorithm which _initially_
> backs off more quickly upon receipt of an ECN mark, but after a few RTTs
> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
> a concept worth research.

It would have been nice if ECN had originally been specified to signal
congestion sooner, but since it wasn't, it isn't clear how to migrate
to a system that does, without breaking things.

As Bob Briscoe has argued
<http://www.ietf.org/mail-archive/web/ledbat/current/msg00479.html>,
it causes problems for algorithms (such as standard TCP) that don't
distinguish between ECN and loss.  If ECN occurs sooner, it causes
ECN-aware flows to be starved, which is the wrong incentive (as well
as being too harsh).

Cheers,
Lachlan

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

From: [email-masked] (Tony Li)
Date: Fri Jul 15 16:36:12 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi> <[email-masked]>
Message-ID: <[email-masked]>

On Jul 15, 2011, at 6:00 AM, ken carlberg wrote:

> The only thing that comes to mind is non-technical -- simply putting up a wiki page that identifies the ISPs that zero out the ECN bits and hope that they can be nudged (shamed?) into changing their practices.

Dropping a periodic message to the Nanog mailing list has been reasonably effective in helping raise awareness of routing table aggregation issues.  

Tony

From: [email-masked] (ken carlberg)
Date: Fri Jul 15 14:43:53 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

sorry, I probably wasn't clear enough in my response.  I agree that it would be helpful to add incentives for end-host support of ECN.  And I find what Lachlan has proposed as interesting, though it would be nice to see a more extensive description of the ideas.  And perhaps in following John's point of how this could be done, perhaps an experimental draft-rfc could be written in order for the wider community to comment on.

However, the end-point part of the ECN model is only one part of the picture of where we need more deployed support.  A while back, one of my interns did some testing and found that a number of ISPs zero out the ECN field in IP packets, thereby nulling any potential ECN support for end-to-end paths transiting that ISP.  And this needs to be addressed regardless of what ever additional end-host support is used to encourage the use of ECN.

-ken

On Jul 15, 2011, at 9:17 AM, Michael Welzl wrote:

> ... but from an endpoint's perspective, relying on ECN in addition to loss is then no worse than relying on loss alone.
> 
> So this doesn't seem to be a reason for an endpoint not to use ECN as Lachlan/Jana suggested.
> 
> Cheers,
> Michael
> 
> 
> On Jul 15, 2011, at 3:00 PM, ken carlberg wrote:
> 
>> There is also the issue of some ISPs zero'ing out the entire old ToS byte instead of only the diff-serv code points.  CONEX is one indirect incentive to change this practice so as to not touch the ECN bits in the IP header, but I think a stronger incentive is needed.  The only thing that comes to mind is non-technical -- simply putting up a wiki page that identifies the ISPs that zero out the ECN bits and hope that they can be nudged (shamed?) into changing their practices.
>> 
>> -ken
>> 
>> 
>> On Jul 15, 2011, at 8:27 AM, John Leslie wrote:
>> 
>>> Lachlan Andrew <[email-masked]> wrote:
>>>> 
>>>> There was some discussion on LEDBAT recently about how to motivate
>>>> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
>>>> suggested may be better followed up in ICCRG.
>>> 
>>> True...
>>> 
>>>> My understanding is that it is "essentially" impossible to give an
>>>> incentive if we follow the letter of RFC3168, which says ECN must be
>>>> treated "essentially" identically to loss.
>>> 
>>> That requirement has proven less than helpful.
>>> 
>>>> That requirement was written in the days when "TCP friendliness" was
>>>> seen as essential. These days, there are many proposals that do not
>>>> aim for TCP friendliness (either being less aggressive like LEDBAT,
>>>> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
>>>> to revisit the requirement that ECN be treated the same as loss.
>>> 
>>> I thoroughly agree -- but _how_ do we revisit it?
>>> 
>>> As a research question, that's entirely appropriate for ICCRG.
>>> 
>>>> People may argue that if one flow backs off less because it is
>>>> receiving ECN instead of loss, then this is "unfair" to the one
>>>> experiencing loss.  I would argue that "fair" = "no incentive".
>>> 
>>> I always argue that "fair" is one grade below "good" ;^)
>>> 
>>> But I must agree "fair" and "incentive" are often mutually
>>> exclusive. :^(
>>> 
>>>> I would propose that the ICCRG assess any new congestion control
>>>> algorithm (for "safety", "fairness" or whatever) on the assumption
>>>> that the flow may receive either ECN or loss while competing flows
>>>> receive loss.  If this gives acceptable performance, then there is no
>>>> need to require equal treatment of ECN and loss.
>>> 
>>> Interesting...
>>> 
>>> I would suggest that the essential feature of ECN is that it delivers
>>> a congestion signal _sooner_ -- so a CC algorithm which _initially_
>>> backs off more quickly upon receipt of an ECN mark, but after a few RTTs
>>> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
>>> a concept worth research.
>>> 
>>>> Of course, any such algorithm is not RFC3168 *compliant*, but it can
>>>> still be RFC3168 *compatible*.
>>> 
>>> :^)
>>> 
>>> --
>>> John Leslie <[email-masked]>
>>> 
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> 
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Fri Jul 15 14:17:29 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi> <[email-masked]>
Message-ID: <[email-masked]>

... but from an endpoint's perspective, relying on ECN in addition to  
loss is then no worse than relying on loss alone.

So this doesn't seem to be a reason for an endpoint not to use ECN as  
Lachlan/Jana suggested.

Cheers,
Michael

On Jul 15, 2011, at 3:00 PM, ken carlberg wrote:

> There is also the issue of some ISPs zero'ing out the entire old ToS  
> byte instead of only the diff-serv code points.  CONEX is one  
> indirect incentive to change this practice so as to not touch the  
> ECN bits in the IP header, but I think a stronger incentive is  
> needed.  The only thing that comes to mind is non-technical --  
> simply putting up a wiki page that identifies the ISPs that zero out  
> the ECN bits and hope that they can be nudged (shamed?) into  
> changing their practices.
>
> -ken
>
>
> On Jul 15, 2011, at 8:27 AM, John Leslie wrote:
>
>> Lachlan Andrew <[email-masked]> wrote:
>>>
>>> There was some discussion on LEDBAT recently about how to motivate
>>> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
>>> suggested may be better followed up in ICCRG.
>>
>>  True...
>>
>>> My understanding is that it is "essentially" impossible to give an
>>> incentive if we follow the letter of RFC3168, which says ECN must be
>>> treated "essentially" identically to loss.
>>
>>  That requirement has proven less than helpful.
>>
>>> That requirement was written in the days when "TCP friendliness" was
>>> seen as essential. These days, there are many proposals that do not
>>> aim for TCP friendliness (either being less aggressive like LEDBAT,
>>> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
>>> to revisit the requirement that ECN be treated the same as loss.
>>
>>  I thoroughly agree -- but _how_ do we revisit it?
>>
>>  As a research question, that's entirely appropriate for ICCRG.
>>
>>> People may argue that if one flow backs off less because it is
>>> receiving ECN instead of loss, then this is "unfair" to the one
>>> experiencing loss.  I would argue that "fair" = "no incentive".
>>
>>  I always argue that "fair" is one grade below "good" ;^)
>>
>>  But I must agree "fair" and "incentive" are often mutually
>> exclusive. :^(
>>
>>> I would propose that the ICCRG assess any new congestion control
>>> algorithm (for "safety", "fairness" or whatever) on the assumption
>>> that the flow may receive either ECN or loss while competing flows
>>> receive loss.  If this gives acceptable performance, then there is  
>>> no
>>> need to require equal treatment of ECN and loss.
>>
>>  Interesting...
>>
>>  I would suggest that the essential feature of ECN is that it  
>> delivers
>> a congestion signal _sooner_ -- so a CC algorithm which _initially_
>> backs off more quickly upon receipt of an ECN mark, but after a few  
>> RTTs
>> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
>> a concept worth research.
>>
>>> Of course, any such algorithm is not RFC3168 *compliant*, but it can
>>> still be RFC3168 *compatible*.
>>
>>  :^)
>>
>> --
>> John Leslie <[email-masked]>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (ken carlberg)
Date: Fri Jul 15 14:00:14 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <20110715122756.GC32499@verdi>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi>
Message-ID: <[email-masked]>

There is also the issue of some ISPs zero'ing out the entire old ToS byte instead of only the diff-serv code points.  CONEX is one indirect incentive to change this practice so as to not touch the ECN bits in the IP header, but I think a stronger incentive is needed.  The only thing that comes to mind is non-technical -- simply putting up a wiki page that identifies the ISPs that zero out the ECN bits and hope that they can be nudged (shamed?) into changing their practices.

-ken

On Jul 15, 2011, at 8:27 AM, John Leslie wrote:

> Lachlan Andrew <[email-masked]> wrote:
>> 
>> There was some discussion on LEDBAT recently about how to motivate
>> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
>> suggested may be better followed up in ICCRG.
> 
>   True...
> 
>> My understanding is that it is "essentially" impossible to give an
>> incentive if we follow the letter of RFC3168, which says ECN must be
>> treated "essentially" identically to loss.
> 
>   That requirement has proven less than helpful.
> 
>> That requirement was written in the days when "TCP friendliness" was
>> seen as essential. These days, there are many proposals that do not
>> aim for TCP friendliness (either being less aggressive like LEDBAT,
>> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
>> to revisit the requirement that ECN be treated the same as loss.
> 
>   I thoroughly agree -- but _how_ do we revisit it?
> 
>   As a research question, that's entirely appropriate for ICCRG.
> 
>> People may argue that if one flow backs off less because it is
>> receiving ECN instead of loss, then this is "unfair" to the one
>> experiencing loss.  I would argue that "fair" = "no incentive".
> 
>   I always argue that "fair" is one grade below "good" ;^)
> 
>   But I must agree "fair" and "incentive" are often mutually
> exclusive. :^(
> 
>> I would propose that the ICCRG assess any new congestion control
>> algorithm (for "safety", "fairness" or whatever) on the assumption
>> that the flow may receive either ECN or loss while competing flows
>> receive loss.  If this gives acceptable performance, then there is no
>> need to require equal treatment of ECN and loss.
> 
>   Interesting...
> 
>   I would suggest that the essential feature of ECN is that it delivers
> a congestion signal _sooner_ -- so a CC algorithm which _initially_
> backs off more quickly upon receipt of an ECN mark, but after a few RTTs
> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
> a concept worth research.
> 
>> Of course, any such algorithm is not RFC3168 *compliant*, but it can
>> still be RFC3168 *compatible*.
> 
>   :^)
> 
> --
> John Leslie <[email-masked]>
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Fri Jul 15 13:55:20 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <20110715122756.GC32499@verdi>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]> <20110715122756.GC32499@verdi>
Message-ID: <[email-masked]>

I agree with all of that, with my chair hat on and off.

Cheers,
Michael

On Jul 15, 2011, at 2:27 PM, John Leslie wrote:

> Lachlan Andrew <[email-masked]> wrote:
>>
>> There was some discussion on LEDBAT recently about how to motivate
>> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
>> suggested may be better followed up in ICCRG.
>
>   True...
>
>> My understanding is that it is "essentially" impossible to give an
>> incentive if we follow the letter of RFC3168, which says ECN must be
>> treated "essentially" identically to loss.
>
>   That requirement has proven less than helpful.
>
>> That requirement was written in the days when "TCP friendliness" was
>> seen as essential. These days, there are many proposals that do not
>> aim for TCP friendliness (either being less aggressive like LEDBAT,
>> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
>> to revisit the requirement that ECN be treated the same as loss.
>
>   I thoroughly agree -- but _how_ do we revisit it?
>
>   As a research question, that's entirely appropriate for ICCRG.
>
>> People may argue that if one flow backs off less because it is
>> receiving ECN instead of loss, then this is "unfair" to the one
>> experiencing loss.  I would argue that "fair" = "no incentive".
>
>   I always argue that "fair" is one grade below "good" ;^)
>
>   But I must agree "fair" and "incentive" are often mutually
> exclusive. :^(
>
>> I would propose that the ICCRG assess any new congestion control
>> algorithm (for "safety", "fairness" or whatever) on the assumption
>> that the flow may receive either ECN or loss while competing flows
>> receive loss.  If this gives acceptable performance, then there is no
>> need to require equal treatment of ECN and loss.
>
>   Interesting...
>
>   I would suggest that the essential feature of ECN is that it  
> delivers
> a congestion signal _sooner_ -- so a CC algorithm which _initially_
> backs off more quickly upon receipt of an ECN mark, but after a few  
> RTTs
> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
> a concept worth research.
>
>> Of course, any such algorithm is not RFC3168 *compliant*, but it can
>> still be RFC3168 *compatible*.
>
>   :^)
>
> --
> John Leslie <[email-masked]>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (John Leslie)
Date: Fri Jul 15 13:27:47 2011
Subject: [Iccrg] Incentives for ECN
In-Reply-To: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]>
References: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]>
Message-ID: <20110715122756.GC32499@verdi>

Lachlan Andrew <[email-masked]> wrote:
> 
> There was some discussion on LEDBAT recently about how to motivate
> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
> suggested may be better followed up in ICCRG.

   True...

> My understanding is that it is "essentially" impossible to give an
> incentive if we follow the letter of RFC3168, which says ECN must be
> treated "essentially" identically to loss.

   That requirement has proven less than helpful.

> That requirement was written in the days when "TCP friendliness" was
> seen as essential. These days, there are many proposals that do not
> aim for TCP friendliness (either being less aggressive like LEDBAT,
> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
> to revisit the requirement that ECN be treated the same as loss.

   I thoroughly agree -- but _how_ do we revisit it?

   As a research question, that's entirely appropriate for ICCRG.

> People may argue that if one flow backs off less because it is
> receiving ECN instead of loss, then this is "unfair" to the one
> experiencing loss.  I would argue that "fair" = "no incentive".

   I always argue that "fair" is one grade below "good" ;^)

   But I must agree "fair" and "incentive" are often mutually
exclusive. :^(

> I would propose that the ICCRG assess any new congestion control
> algorithm (for "safety", "fairness" or whatever) on the assumption
> that the flow may receive either ECN or loss while competing flows
> receive loss.  If this gives acceptable performance, then there is no
> need to require equal treatment of ECN and loss.

   Interesting...

   I would suggest that the essential feature of ECN is that it delivers
a congestion signal _sooner_ -- so a CC algorithm which _initially_
backs off more quickly upon receipt of an ECN mark, but after a few RTTs
perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
a concept worth research.

> Of course, any such algorithm is not RFC3168 *compliant*, but it can
> still be RFC3168 *compatible*.

   :^)

--
John Leslie <[email-masked]>

From: [email-masked] (Lachlan Andrew)
Date: Fri Jul 15 10:00:29 2011
Subject: [Iccrg] Incentives for ECN
Message-ID: <CAPpWWaLVPRHn9czPYv+t_D_sqg-1YQKQDmuAVFd+GH7+5ZAF=[email-masked]>

Greetings all,

There was some discussion on LEDBAT recently about how to motivate
users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
suggested may be better followed up in ICCRG.

My understanding is that it is "essentially" impossible to give an
incentive if we follow the letter of RFC3168, which says ECN must be
treated "essentially" identically to loss.  That requirement was
written in the days when "TCP friendliness" was seen as essential.
These days, there are many proposals that do not aim for TCP
friendliness (either being less aggressive like LEDBAT, or more
aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time to
revisit the requirement that ECN be treated the same as loss.

People may argue that if one flow backs off less because it is
receiving ECN instead of loss, then this is "unfair" to the one
experiencing loss.  I would argue that "fair" = "no incentive".

I would propose that the ICCRG assess any new congestion control
algorithm (for "safety", "fairness" or whatever) on the assumption
that the flow may receive either ECN or loss while competing flows
receive loss.  If this gives acceptable performance, then there is no
need to require equal treatment of ECN and loss.

Of course, any such algorithm is not RFC3168 *compliant*, but it can
still be RFC3168 *compatible*.

Thoughts?

Lachlan

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

From: [email-masked] (David Hayes)
Date: Fri Jul 15 03:57:27 2011
Subject: [Iccrg] An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I am revising the TCP evaluation test suite draft (see
http://tools.ietf.org/html/draft-irtf-tmrg-tests-02), and implementing the
revised proposals in ns2.

This proposal for a "benchmark" test suite to look at an aggressiveness metric
is very similar to 
http://tools.ietf.org/html/draft-irtf-tmrg-tests-02#section-3.5

I will be working on this part shortly. What does the group think of the idea
presented in section-3.5 for this type of application?

Alternatives? Improvements? Enhancements?

Regards,

David

PS
Work on this test suite will be eventually available at
http://caia.swin.edu.au/ngen/tcptestsuite/

On Fri, Jul 15, 2011 at 12:28:18AM +0200, Michael Welzl wrote:
> (sending to ICCRG with Dirceu's permission)
> 
> Hi,
> 
> Regarding your first point about similar network conditions, I think  
> the metric should be coupled with a simple "benchmark" test suite.
> 
> Regarding your second point, that such a metric "only serves to  
> heighten the theoretical discussion about fairness", how do you think  
> that developing more advanced schemes might make this discussion  
> irrelevant?
> I don't see how we would agree on a "perfect" level of aggression, as  
> experienced by users running standard TCP. Isn't assigning a simple  
> number to schemes as good as it gets, then?
> 
> Michael
> 
> 
> On Jul 14, 2011, at 10:48 PM, Dirceu Cavendish wrote:
> 
> > Michael,
> >
> > Here is my two cents on the relevance of an aggressiveness metric.  
> > For comparison purposes, any such metric (aM) will require similar  
> > network conditions, e.g., sessions starting at the same time, ending  
> > at the same time, same rtt, same packet loss probability, etc. To  
> > me, such an aM metric has little practical relevance, as TCP  
> > sessions sharing a bottleneck will rarely match these conditions  
> > between them...Such a metric only serves to heighten the theoretical  
> > discussions about fairness that, imho, may be straightjacketing the  
> > development of more advanced TCP congestion control (CA) schemes.
> >
> > Rgds,
> > Dirceu
> >
> > From: Michael Welzl <[email-masked]>
> > To: Lisong Xu <[email-masked]>
> > Cc: "[email-masked] list" <[email-masked]>
> > Sent: Thu, July 14, 2011 12:27:53 PM
> > Subject: Re: [Iccrg] An aggression metric?
> >
> >
> > On Jul 14, 2011, at 7:05 PM, Lisong Xu wrote:
> >
> > > Hi Michael,
> > >
> > > This is an interesting idea. But it may be hard to get a single  
> > number N, since this number may be different for different packet  
> > loss rates and base RTTs.
> >
> > Well, it could be a simple from-to range. But of course, we could  
> > find that, then, all mechanisms are in the same, huge range  :)
> >
> >
> > > A similar method is to compare the response function (where N is  
> > also a function), which captures more information of the  
> > "aggression" of a congestion control mechanism.
> >
> > Hm, that's closer to Bob's proposal. Finer grained but less  
> > practical perhaps. Or maybe not.
> >
> > More voices please: is this even relevant, important, worth  
> > investigating?
> >
> > Michael
> >
> >
> >
> > >
> > > Lisong
> > >
> > > On 7/14/2011 2:15 AM, Michael Welzl wrote:
> > >> Hi!
> > >>
> > >> Here's an idea. Our group's charter says: "The key goal of the  
> > Internet
> > >> Congestion Control Research Group (ICCRG) therefore is to move  
> > towards
> > >> consensus on which technologies are viable long-term solutions  
> > for the
> > >> Internet congestion control architecture, and what an appropriate
> > >> cost/benefit tradeoff is."
> > >>
> > >> For a "viable long-term solution", I think that the "aggression"  
> > of a
> > >> congestion control mechanism is important, but most evaluations  
> > focus on
> > >> its efficiency in terms of bandwidth utilization, fairness among  
> > flows
> > >> of their own kind, etc. By aggression, I mean:
> > >> - what happens when it fights against a standard TCP?
> > >> - what happens when it fights against its competitors, e.g.  
> > (insert your
> > >> favorite mechanism here)?
> > >> It's not uncommon to have a diagram that shows one of these  
> > things in
> > >> papers too, but what would really be good, I think, would be to  
> > have a
> > >> unified way of looking at it - an aggression metric. Something  
> > that lets
> > >> me conclude that, e.g., CUBIC is 7-aggressive, HTCP is also 7- 
> > aggressive
> > >> (of course these two are surely equal! he he :) ), FAST is 3- 
> > aggressive,
> > >> Westwood is 12-aggressive, whatever! Something like that.
> > >>
> > >> Standard TCP could be the base unit (the number 1) here. We  
> > recently
> > >> finished a paper in which we present an extension of the TCP
> > >> steady-state throughput equation for multiple flows - i.e. from the
> > >> packet size, loss event rate, RTT, and now also the number of  
> > flows (N)
> > >> and the actual packet loss ratio, one can calculate the rate at  
> > which N
> > >> flows would send. This is the paper:
> > >>
> > >> Dragana Damjanovic, Michael Welzl: "An Extension of the TCP  
> > Steady-State
> > >> Throughput Equation for Parallel Flows and its Application in  
> > MulTFRC",
> > >> accepted for publication in IEEE/ACM Transactions on Networking,  
> > 2011.
> > >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
> > >>
> > >> The equation is also included in our MulTFRC draft:
> > >> http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
> > >> (btw, we're just about to finish an update of this document, stay  
> > tuned)
> > >>
> > >> It wouldn't be hard to turn this equation around such that, from  
> > the
> > >> packet size, loss event rate, RTT, packet loss ratio and sending  
> > rate,
> > >> one could calculate how many standard TCP's (N) must have  
> > produced (or
> > >> would be represented by) this rate. This would also work with  
> > floats,
> > >> e.g. a calculation could yield N=3.52 or something like that.  
> > Thus, one
> > >> could carry out a "benchmark test" simulation of a high-speed  
> > mechanism
> > >> where it's confronted with different loss and RTT conditions, and  
> > from
> > >> its resulting rate, one could then say that it's between X and
> > >> Y-aggressive, i.e. representing between X and Y TCPs.
> > >>
> > >> Would that be a useful "aggression" metric?
> > >>
> > >> e.g. an alternative could be to produce a simpler equation which  
> > is not
> > >> so much based on all the specifics of TCP (slow start etc), maybe  
> > just
> > >> use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP with slow  
> > start
> > >> stands in relation to that, and where high-speed mechanisms stand  
> > in
> > >> relation to that. Or should use an even simpler equation?
> > >>
> > >> Do we even need or want such a metric?
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Iccrg mailing list
> > >> [email-masked]
> > >> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> > >
> > > --Lisong Xu, Associate Professor
> > > Computer Science & Engineering
> > > University of Nebraska-Lincoln
> > > http://cse.unl.edu/~xu
> >
> >
> > _______________________________________________
> > Iccrg mailing list
> > [email-masked]
> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
David Hayes
Research Associate
Centre for Advanced Internet Architectures
Faculty of Information and Communication Technologies
Swinburne University of Technology, Australia
http://caia.swin.edu.au/cv/dahayes/
Alternate Email: [email-masked]

From: [email-masked] (Lachlan Andrew)
Date: Fri Jul 15 03:00:52 2011
Subject: [Iccrg] Re: [tmrg] Fwd: An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CAPpWWaJR+wJWVYP-zRGRa=[email-masked]>

Greetings,

Many new TPC variants are sensitive to things other than the average
loss rate.  For example, CUBIC depends heavily on the burstiness of
the losses, while LEDBAT and CTCP also depend on delay.

It is difficult to find a fundamental "congestion p(t)" that reflects
the notion of congestion seen by all flows.  Steven Low and Kevin Tang
presented some theoretical work on this in INFOCOM 2005.

The notion "congestion = average loss rate" is already too entrenched
IMHO.  It would be great to be able to measure aggression, but a
simple scalar (or even a scalar function of scalar congestion measure)
may not add much insight.

$0.02,
Lachlan

On 14 July 2011 20:22, Bob Briscoe <[email-masked]> wrote:
> Michael,
>
> Congestion-rate fulfils the role of measuring the aggression of a flow,
> doesn't it? And it is in objective units of b/s, avoiding being relative to
> TCP which is what you're looking for.
>
> Congestion-bit-rate is the bit-rate at which congestion events (losses or
> ECN marks) are generated or experienced, for a flow or any other aggregate.
> It measures the response of bit-rate to congestion, which is another way of
> saying aggression.
>
> In a fluid model, congestion-rate, v(t), is the instantaneous product of
> bit-rate x(t) and congestion p(t):
> v(t) = p(t)x(t)
>
> At first I thought this wouldn't be right as a measure of aggression,
> because for TCP it depends on congestion, so I was trying to normalise it to
> be independent of congestion. However, I realised dependence of aggression
> on congestion is a feature of TCP: as congestion rises, aggression rises.
> Also, aggression depends on RTT for TCP.
>
> Taking the simplest TCP macro-model:
> ? ? ? ?x = K/(R.sqrt(p))
> where K is a constant, and R is RTT. Then the congestion-rate,
> ? ? ? ?v = K.sqrt(p)/R
>
> For a proportionally fair congestion control that converges to a rate
> independent of RTT:
> ? ? ? ?x = wp
> where w is the weight (similar role to TCP's constant). Then
> congestion-rate,
> ? ? ? ?v = w
> That is, the weight is the aggression of this flow.

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

From: [email-masked] (Michael Welzl)
Date: Thu Jul 14 23:28:32 2011
Subject: [Iccrg] An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

(sending to ICCRG with Dirceu's permission)

Hi,

Regarding your first point about similar network conditions, I think  
the metric should be coupled with a simple "benchmark" test suite.

Regarding your second point, that such a metric "only serves to  
heighten the theoretical discussion about fairness", how do you think  
that developing more advanced schemes might make this discussion  
irrelevant?
I don't see how we would agree on a "perfect" level of aggression, as  
experienced by users running standard TCP. Isn't assigning a simple  
number to schemes as good as it gets, then?

Michael

On Jul 14, 2011, at 10:48 PM, Dirceu Cavendish wrote:

> Michael,
>
> Here is my two cents on the relevance of an aggressiveness metric.  
> For comparison purposes, any such metric (aM) will require similar  
> network conditions, e.g., sessions starting at the same time, ending  
> at the same time, same rtt, same packet loss probability, etc. To  
> me, such an aM metric has little practical relevance, as TCP  
> sessions sharing a bottleneck will rarely match these conditions  
> between them...Such a metric only serves to heighten the theoretical  
> discussions about fairness that, imho, may be straightjacketing the  
> development of more advanced TCP congestion control (CA) schemes.
>
> Rgds,
> Dirceu
>
> From: Michael Welzl <[email-masked]>
> To: Lisong Xu <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
> Sent: Thu, July 14, 2011 12:27:53 PM
> Subject: Re: [Iccrg] An aggression metric?
>
>
> On Jul 14, 2011, at 7:05 PM, Lisong Xu wrote:
>
> > Hi Michael,
> >
> > This is an interesting idea. But it may be hard to get a single  
> number N, since this number may be different for different packet  
> loss rates and base RTTs.
>
> Well, it could be a simple from-to range. But of course, we could  
> find that, then, all mechanisms are in the same, huge range  :)
>
>
> > A similar method is to compare the response function (where N is  
> also a function), which captures more information of the  
> "aggression" of a congestion control mechanism.
>
> Hm, that's closer to Bob's proposal. Finer grained but less  
> practical perhaps. Or maybe not.
>
> More voices please: is this even relevant, important, worth  
> investigating?
>
> Michael
>
>
>
> >
> > Lisong
> >
> > On 7/14/2011 2:15 AM, Michael Welzl wrote:
> >> Hi!
> >>
> >> Here's an idea. Our group's charter says: "The key goal of the  
> Internet
> >> Congestion Control Research Group (ICCRG) therefore is to move  
> towards
> >> consensus on which technologies are viable long-term solutions  
> for the
> >> Internet congestion control architecture, and what an appropriate
> >> cost/benefit tradeoff is."
> >>
> >> For a "viable long-term solution", I think that the "aggression"  
> of a
> >> congestion control mechanism is important, but most evaluations  
> focus on
> >> its efficiency in terms of bandwidth utilization, fairness among  
> flows
> >> of their own kind, etc. By aggression, I mean:
> >> - what happens when it fights against a standard TCP?
> >> - what happens when it fights against its competitors, e.g.  
> (insert your
> >> favorite mechanism here)?
> >> It's not uncommon to have a diagram that shows one of these  
> things in
> >> papers too, but what would really be good, I think, would be to  
> have a
> >> unified way of looking at it - an aggression metric. Something  
> that lets
> >> me conclude that, e.g., CUBIC is 7-aggressive, HTCP is also 7- 
> aggressive
> >> (of course these two are surely equal! he he :) ), FAST is 3- 
> aggressive,
> >> Westwood is 12-aggressive, whatever! Something like that.
> >>
> >> Standard TCP could be the base unit (the number 1) here. We  
> recently
> >> finished a paper in which we present an extension of the TCP
> >> steady-state throughput equation for multiple flows - i.e. from the
> >> packet size, loss event rate, RTT, and now also the number of  
> flows (N)
> >> and the actual packet loss ratio, one can calculate the rate at  
> which N
> >> flows would send. This is the paper:
> >>
> >> Dragana Damjanovic, Michael Welzl: "An Extension of the TCP  
> Steady-State
> >> Throughput Equation for Parallel Flows and its Application in  
> MulTFRC",
> >> accepted for publication in IEEE/ACM Transactions on Networking,  
> 2011.
> >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
> >>
> >> The equation is also included in our MulTFRC draft:
> >> http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
> >> (btw, we're just about to finish an update of this document, stay  
> tuned)
> >>
> >> It wouldn't be hard to turn this equation around such that, from  
> the
> >> packet size, loss event rate, RTT, packet loss ratio and sending  
> rate,
> >> one could calculate how many standard TCP's (N) must have  
> produced (or
> >> would be represented by) this rate. This would also work with  
> floats,
> >> e.g. a calculation could yield N=3.52 or something like that.  
> Thus, one
> >> could carry out a "benchmark test" simulation of a high-speed  
> mechanism
> >> where it's confronted with different loss and RTT conditions, and  
> from
> >> its resulting rate, one could then say that it's between X and
> >> Y-aggressive, i.e. representing between X and Y TCPs.
> >>
> >> Would that be a useful "aggression" metric?
> >>
> >> e.g. an alternative could be to produce a simpler equation which  
> is not
> >> so much based on all the specifics of TCP (slow start etc), maybe  
> just
> >> use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP with slow  
> start
> >> stands in relation to that, and where high-speed mechanisms stand  
> in
> >> relation to that. Or should use an even simpler equation?
> >>
> >> Do we even need or want such a metric?
> >>
> >> Cheers,
> >> Michael
> >>
> >>
> >> _______________________________________________
> >> Iccrg mailing list
> >> [email-masked]
> >> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> >
> > --Lisong Xu, Associate Professor
> > Computer Science & Engineering
> > University of Nebraska-Lincoln
> > http://cse.unl.edu/~xu
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Thu Jul 14 20:28:08 2011
Subject: [Iccrg] An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Jul 14, 2011, at 7:05 PM, Lisong Xu wrote:

> Hi Michael,
>
> This is an interesting idea. But it may be hard to get a single  
> number N, since this number may be different for different packet  
> loss rates and base RTTs.

Well, it could be a simple from-to range. But of course, we could find  
that, then, all mechanisms are in the same, huge range  :)

> A similar method is to compare the response function (where N is  
> also a function), which captures more information of the  
> "aggression" of a congestion control mechanism.

Hm, that's closer to Bob's proposal. Finer grained but less practical  
perhaps. Or maybe not.

More voices please: is this even relevant, important, worth  
investigating?

Michael

>
> Lisong
>
> On 7/14/2011 2:15 AM, Michael Welzl wrote:
>> Hi!
>>
>> Here's an idea. Our group's charter says: "The key goal of the  
>> Internet
>> Congestion Control Research Group (ICCRG) therefore is to move  
>> towards
>> consensus on which technologies are viable long-term solutions for  
>> the
>> Internet congestion control architecture, and what an appropriate
>> cost/benefit tradeoff is."
>>
>> For a "viable long-term solution", I think that the "aggression" of a
>> congestion control mechanism is important, but most evaluations  
>> focus on
>> its efficiency in terms of bandwidth utilization, fairness among  
>> flows
>> of their own kind, etc. By aggression, I mean:
>> - what happens when it fights against a standard TCP?
>> - what happens when it fights against its competitors, e.g. (insert  
>> your
>> favorite mechanism here)?
>> It's not uncommon to have a diagram that shows one of these things in
>> papers too, but what would really be good, I think, would be to  
>> have a
>> unified way of looking at it - an aggression metric. Something that  
>> lets
>> me conclude that, e.g., CUBIC is 7-aggressive, HTCP is also 7- 
>> aggressive
>> (of course these two are surely equal! he he :) ), FAST is 3- 
>> aggressive,
>> Westwood is 12-aggressive, whatever! Something like that.
>>
>> Standard TCP could be the base unit (the number 1) here. We recently
>> finished a paper in which we present an extension of the TCP
>> steady-state throughput equation for multiple flows - i.e. from the
>> packet size, loss event rate, RTT, and now also the number of flows  
>> (N)
>> and the actual packet loss ratio, one can calculate the rate at  
>> which N
>> flows would send. This is the paper:
>>
>> Dragana Damjanovic, Michael Welzl: "An Extension of the TCP Steady- 
>> State
>> Throughput Equation for Parallel Flows and its Application in  
>> MulTFRC",
>> accepted for publication in IEEE/ACM Transactions on Networking,  
>> 2011.
>> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
>>
>> The equation is also included in our MulTFRC draft:
>> http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
>> (btw, we're just about to finish an update of this document, stay  
>> tuned)
>>
>> It wouldn't be hard to turn this equation around such that, from the
>> packet size, loss event rate, RTT, packet loss ratio and sending  
>> rate,
>> one could calculate how many standard TCP's (N) must have produced  
>> (or
>> would be represented by) this rate. This would also work with floats,
>> e.g. a calculation could yield N=3.52 or something like that. Thus,  
>> one
>> could carry out a "benchmark test" simulation of a high-speed  
>> mechanism
>> where it's confronted with different loss and RTT conditions, and  
>> from
>> its resulting rate, one could then say that it's between X and
>> Y-aggressive, i.e. representing between X and Y TCPs.
>>
>> Would that be a useful "aggression" metric?
>>
>> e.g. an alternative could be to produce a simpler equation which is  
>> not
>> so much based on all the specifics of TCP (slow start etc), maybe  
>> just
>> use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP with slow start
>> stands in relation to that, and where high-speed mechanisms stand in
>> relation to that. Or should use an even simpler equation?
>>
>> Do we even need or want such a metric?
>>
>> Cheers,
>> Michael
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
> -- 
> Lisong Xu, Associate Professor
> Computer Science & Engineering
> University of Nebraska-Lincoln
> http://cse.unl.edu/~xu

From: [email-masked] (Lisong Xu)
Date: Thu Jul 14 18:05:45 2011
Subject: [Iccrg] An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Michael,

This is an interesting idea. But it may be hard to get a single number 
N, since this number may be different for different packet loss rates 
and base RTTs.

A similar method is to compare the response function (where N is also a 
function), which captures more information of the "aggression" of a 
congestion control mechanism.

Lisong

On 7/14/2011 2:15 AM, Michael Welzl wrote:
> Hi!
>
> Here's an idea. Our group's charter says: "The key goal of the Internet
> Congestion Control Research Group (ICCRG) therefore is to move towards
> consensus on which technologies are viable long-term solutions for the
> Internet congestion control architecture, and what an appropriate
> cost/benefit tradeoff is."
>
> For a "viable long-term solution", I think that the "aggression" of a
> congestion control mechanism is important, but most evaluations focus on
> its efficiency in terms of bandwidth utilization, fairness among flows
> of their own kind, etc. By aggression, I mean:
> - what happens when it fights against a standard TCP?
> - what happens when it fights against its competitors, e.g. (insert your
> favorite mechanism here)?
> It's not uncommon to have a diagram that shows one of these things in
> papers too, but what would really be good, I think, would be to have a
> unified way of looking at it - an aggression metric. Something that lets
> me conclude that, e.g., CUBIC is 7-aggressive, HTCP is also 7-aggressive
> (of course these two are surely equal! he he :) ), FAST is 3-aggressive,
> Westwood is 12-aggressive, whatever! Something like that.
>
> Standard TCP could be the base unit (the number 1) here. We recently
> finished a paper in which we present an extension of the TCP
> steady-state throughput equation for multiple flows - i.e. from the
> packet size, loss event rate, RTT, and now also the number of flows (N)
> and the actual packet loss ratio, one can calculate the rate at which N
> flows would send. This is the paper:
>
> Dragana Damjanovic, Michael Welzl: "An Extension of the TCP Steady-State
> Throughput Equation for Parallel Flows and its Application in MulTFRC",
> accepted for publication in IEEE/ACM Transactions on Networking, 2011.
> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
>
> The equation is also included in our MulTFRC draft:
> http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
> (btw, we're just about to finish an update of this document, stay tuned)
>
> It wouldn't be hard to turn this equation around such that, from the
> packet size, loss event rate, RTT, packet loss ratio and sending rate,
> one could calculate how many standard TCP's (N) must have produced (or
> would be represented by) this rate. This would also work with floats,
> e.g. a calculation could yield N=3.52 or something like that. Thus, one
> could carry out a "benchmark test" simulation of a high-speed mechanism
> where it's confronted with different loss and RTT conditions, and from
> its resulting rate, one could then say that it's between X and
> Y-aggressive, i.e. representing between X and Y TCPs.
>
> Would that be a useful "aggression" metric?
>
> e.g. an alternative could be to produce a simpler equation which is not
> so much based on all the specifics of TCP (slow start etc), maybe just
> use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP with slow start
> stands in relation to that, and where high-speed mechanisms stand in
> relation to that. Or should use an even simpler equation?
>
> Do we even need or want such a metric?
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
Lisong Xu, Associate Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

From: [email-masked] (Michael Welzl)
Date: Thu Jul 14 11:38:24 2011
Subject: [Iccrg] Re: [tmrg] Fwd: An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Thanks, I think that's going in the right direction!

A disadvantage of your proposed measure is that it's maybe too fine  
grained to be practical. v = K.sqrt(p)/R is still a function of p and  
R, whereas what I proposed before is a number, or a number range based  
on a benchmark test, leading to a simple statement like "the  
aggression of this mechanism is between X and Y".

Of course, with a generic statement like that, you lose some  
information, i.e. the function gives you a more precise notion of  
"aggression"...

What do we need? What do others think?  :-)

Michael

On Jul 14, 2011, at 12:22 PM, Bob Briscoe wrote:

> Michael,
>
> Congestion-rate fulfils the role of measuring the aggression of a  
> flow, doesn't it? And it is in objective units of b/s, avoiding  
> being relative to TCP which is what you're looking for.
>
> Congestion-bit-rate is the bit-rate at which congestion events  
> (losses or ECN marks) are generated or experienced, for a flow or  
> any other aggregate. It measures the response of bit-rate to  
> congestion, which is another way of saying aggression.
>
> In a fluid model, congestion-rate, v(t), is the instantaneous  
> product of bit-rate x(t) and congestion p(t):
> v(t) = p(t)x(t)
>
> At first I thought this wouldn't be right as a measure of  
> aggression, because for TCP it depends on congestion, so I was  
> trying to normalise it to be independent of congestion. However, I  
> realised dependence of aggression on congestion is a feature of TCP:  
> as congestion rises, aggression rises. Also, aggression depends on  
> RTT for TCP.
>
> Taking the simplest TCP macro-model:
>        x = K/(R.sqrt(p))
> where K is a constant, and R is RTT. Then the congestion-rate,
>        v = K.sqrt(p)/R
>
> For a proportionally fair congestion control that converges to a  
> rate independent of RTT:
>        x = wp
> where w is the weight (similar role to TCP's constant). Then  
> congestion-rate,
>        v = w
> That is, the weight is the aggression of this flow.
>
> Any use?
>
>
> Bob
>
> PS. Tx for cross-posting to tmrg - it flagged to me that I had  
> fallen off iccrg somehow.
>
>
> At 10:17 14/07/2011, Michael Welzl wrote:
>> Hi TMRGers,
>>
>> I sent this message to ICCRG, but I think it should be of interest to
>> TMRG'ers too, so here I'm forwarding it. Please carry out discussion
>> on the ICCRG list, though.
>>
>> Cheers,
>> Michael
>>
>>
>> Begin forwarded message:
>>
>>> From: Michael Welzl <[email-masked]>
>>> Date: July 14, 2011 11:15:19 AM GMT+02:00
>>> To: "[email-masked] list" <[email-masked]>
>>> Subject: An aggression metric?
>>>
>>> Hi!
>>>
>>> Here's an idea. Our group's charter says: "The key goal of the
>>> Internet Congestion Control Research Group (ICCRG) therefore is to
>>> move towards consensus on which technologies are viable long-term
>>> solutions for the Internet congestion control architecture, and what
>>> an appropriate cost/benefit tradeoff is."
>>>
>>> For a "viable long-term solution", I think that the "aggression" of
>>> a congestion control mechanism is important, but most evaluations
>>> focus on its efficiency in terms of bandwidth utilization, fairness
>>> among flows of their own kind, etc. By aggression, I mean:
>>> - what happens when it fights against a standard TCP?
>>> - what happens when it fights against its competitors, e.g. (insert
>>> your favorite mechanism here)?
>>> It's not uncommon to have a diagram that shows one of these things
>>> in papers too, but what would really be good, I think, would be to
>>> have a unified way of looking at it - an aggression metric.
>>> Something that lets me conclude that, e.g., CUBIC is 7-aggressive,
>>> HTCP is also 7-aggressive (of course these two are surely equal! he
>>> he :)  ), FAST is 3-aggressive, Westwood is 12-aggressive, whatever!
>>> Something like that.
>>>
>>> Standard TCP could be the base unit (the number 1) here. We recently
>>> finished a paper in which we present an extension of the TCP  
>>> steady- state throughput equation for multiple flows - i.e. from  
>>> the packet
>>> size, loss event rate, RTT, and now also the number of flows (N) and
>>> the actual packet loss ratio, one can calculate the rate at which N
>>> flows would send. This is the paper:
>>>
>>> Dragana Damjanovic, Michael Welzl: "An Extension of the TCP  
>>> Steady- State Throughput Equation for Parallel Flows and its  
>>> Application in
>>> MulTFRC", accepted for publication in IEEE/ACM Transactions on
>>> Networking, 2011.
>>> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
>>>
>>> The equation is also included in our MulTFRC draft:
>>> http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
>>> (btw, we're just about to finish an update of this document, stay
>>> tuned)
>>>
>>> It wouldn't be hard to turn this equation around such that, from the
>>> packet size, loss event rate, RTT, packet loss ratio and sending
>>> rate, one could calculate how many standard TCP's (N) must have
>>> produced (or would be represented by) this rate. This would also
>>> work with floats, e.g. a calculation could yield N=3.52 or something
>>> like that. Thus, one could carry out a "benchmark test" simulation
>>> of a high-speed mechanism where it's confronted with different loss
>>> and RTT conditions, and from its resulting rate, one could then say
>>> that it's between X and Y-aggressive, i.e. representing between X
>>> and Y TCPs.
>>>
>>> Would that be a useful "aggression" metric?
>>>
>>> e.g. an alternative could be to produce a simpler equation which is
>>> not so much based on all the specifics of TCP (slow start etc),
>>> maybe just use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP
>>> with slow start stands in relation to that, and where high-speed
>>> mechanisms stand in relation to that. Or should use an even simpler
>>> equation?
>>>
>>> Do we even need or want such a metric?
>>>
>>> Cheers,
>>> Michael
>>
>> _______________________________________________
>> tmrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/tmrg
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design

From: [email-masked] (Bob Briscoe)
Date: Thu Jul 14 11:23:17 2011
Subject: [Iccrg] Re: [tmrg] Fwd: An aggression metric?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael,

Congestion-rate fulfils the role of measuring the aggression of a 
flow, doesn't it? And it is in objective units of b/s, avoiding being 
relative to TCP which is what you're looking for.

Congestion-bit-rate is the bit-rate at which congestion events 
(losses or ECN marks) are generated or experienced, for a flow or any 
other aggregate. It measures the response of bit-rate to congestion, 
which is another way of saying aggression.

In a fluid model, congestion-rate, v(t), is the instantaneous product 
of bit-rate x(t) and congestion p(t):
v(t) = p(t)x(t)

At first I thought this wouldn't be right as a measure of aggression, 
because for TCP it depends on congestion, so I was trying to 
normalise it to be independent of congestion. However, I realised 
dependence of aggression on congestion is a feature of TCP: as 
congestion rises, aggression rises. Also, aggression depends on RTT for TCP.

Taking the simplest TCP macro-model:
         x = K/(R.sqrt(p))
where K is a constant, and R is RTT. Then the congestion-rate,
         v = K.sqrt(p)/R

For a proportionally fair congestion control that converges to a rate 
independent of RTT:
         x = wp
where w is the weight (similar role to TCP's constant). Then congestion-rate,
         v = w
That is, the weight is the aggression of this flow.

Any use?

Bob

PS. Tx for cross-posting to tmrg - it flagged to me that I had fallen 
off iccrg somehow.

At 10:17 14/07/2011, Michael Welzl wrote:
>Hi TMRGers,
>
>I sent this message to ICCRG, but I think it should be of interest to
>TMRG'ers too, so here I'm forwarding it. Please carry out discussion
>on the ICCRG list, though.
>
>Cheers,
>Michael
>
>
>Begin forwarded message:
>
>>From: Michael Welzl <[email-masked]>
>>Date: July 14, 2011 11:15:19 AM GMT+02:00
>>To: "[email-masked] list" <[email-masked]>
>>Subject: An aggression metric?
>>
>>Hi!
>>
>>Here's an idea. Our group's charter says: "The key goal of the
>>Internet Congestion Control Research Group (ICCRG) therefore is to
>>move towards consensus on which technologies are viable long-term
>>solutions for the Internet congestion control architecture, and what
>>an appropriate cost/benefit tradeoff is."
>>
>>For a "viable long-term solution", I think that the "aggression" of
>>a congestion control mechanism is important, but most evaluations
>>focus on its efficiency in terms of bandwidth utilization, fairness
>>among flows of their own kind, etc. By aggression, I mean:
>>- what happens when it fights against a standard TCP?
>>- what happens when it fights against its competitors, e.g. (insert
>>your favorite mechanism here)?
>>It's not uncommon to have a diagram that shows one of these things
>>in papers too, but what would really be good, I think, would be to
>>have a unified way of looking at it - an aggression metric.
>>Something that lets me conclude that, e.g., CUBIC is 7-aggressive,
>>HTCP is also 7-aggressive (of course these two are surely equal! he
>>he :)  ), FAST is 3-aggressive, Westwood is 12-aggressive, whatever!
>>Something like that.
>>
>>Standard TCP could be the base unit (the number 1) here. We recently
>>finished a paper in which we present an extension of the TCP 
>>steady- state throughput equation for multiple flows - i.e. from the packet
>>size, loss event rate, RTT, and now also the number of flows (N) and
>>the actual packet loss ratio, one can calculate the rate at which N
>>flows would send. This is the paper:
>>
>>Dragana Damjanovic, Michael Welzl: "An Extension of the TCP Steady- 
>>State Throughput Equation for Parallel Flows and its Application in
>>MulTFRC", accepted for publication in IEEE/ACM Transactions on
>>Networking, 2011.
>>http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
>>
>>The equation is also included in our MulTFRC draft:
>>http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
>>(btw, we're just about to finish an update of this document, stay
>>tuned)
>>
>>It wouldn't be hard to turn this equation around such that, from the
>>packet size, loss event rate, RTT, packet loss ratio and sending
>>rate, one could calculate how many standard TCP's (N) must have
>>produced (or would be represented by) this rate. This would also
>>work with floats, e.g. a calculation could yield N=3.52 or something
>>like that. Thus, one could carry out a "benchmark test" simulation
>>of a high-speed mechanism where it's confronted with different loss
>>and RTT conditions, and from its resulting rate, one could then say
>>that it's between X and Y-aggressive, i.e. representing between X
>>and Y TCPs.
>>
>>Would that be a useful "aggression" metric?
>>
>>e.g. an alternative could be to produce a simpler equation which is
>>not so much based on all the specifics of TCP (slow start etc),
>>maybe just use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP
>>with slow start stands in relation to that, and where high-speed
>>mechanisms stand in relation to that. Or should use an even simpler
>>equation?
>>
>>Do we even need or want such a metric?
>>
>>Cheers,
>>Michael
>
>_______________________________________________
>tmrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/tmrg

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Michael Welzl)
Date: Thu Jul 14 10:16:05 2011
Subject: [Iccrg] An aggression metric?
Message-ID: <[email-masked]>

Hi!

Here's an idea. Our group's charter says: "The key goal of the  
Internet Congestion Control Research Group (ICCRG) therefore is to  
move towards consensus on which technologies are viable long-term  
solutions for the Internet congestion control architecture, and what  
an appropriate cost/benefit tradeoff is."

For a "viable long-term solution", I think that the "aggression" of a  
congestion control mechanism is important, but most evaluations focus  
on its efficiency in terms of bandwidth utilization, fairness among  
flows of their own kind, etc. By aggression, I mean:
- what happens when it fights against a standard TCP?
- what happens when it fights against its competitors, e.g. (insert  
your favorite mechanism here)?
It's not uncommon to have a diagram that shows one of these things in  
papers too, but what would really be good, I think, would be to have a  
unified way of looking at it - an aggression metric. Something that  
lets me conclude that, e.g., CUBIC is 7-aggressive, HTCP is also 7- 
aggressive (of course these two are surely equal! he he :)  ), FAST is  
3-aggressive, Westwood is 12-aggressive, whatever! Something like that.

Standard TCP could be the base unit (the number 1) here. We recently  
finished a paper in which we present an extension of the TCP steady- 
state throughput equation for multiple flows - i.e. from the packet  
size, loss event rate, RTT, and now also the number of flows (N) and  
the actual packet loss ratio, one can calculate the rate at which N  
flows would send. This is the paper:

Dragana Damjanovic, Michael Welzl: "An Extension of the TCP Steady- 
State Throughput Equation for Parallel Flows and its Application in  
MulTFRC", accepted for publication in IEEE/ACM Transactions on  
Networking, 2011.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1

The equation is also included in our MulTFRC draft:
http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
(btw, we're just about to finish an update of this document, stay tuned)

It wouldn't be hard to turn this equation around such that, from the  
packet size, loss event rate, RTT, packet loss ratio and sending rate,  
one could calculate how many standard TCP's (N) must have produced (or  
would be represented by) this rate. This would also work with floats,  
e.g. a calculation could yield N=3.52 or something like that. Thus,  
one could carry out a "benchmark test" simulation of a high-speed  
mechanism where it's confronted with different loss and RTT  
conditions, and from its resulting rate, one could then say that it's  
between X and Y-aggressive, i.e. representing between X and Y TCPs.

Would that be a useful "aggression" metric?

e.g. an alternative could be to produce a simpler equation which is  
not so much based on all the specifics of TCP (slow start etc), maybe  
just use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP with slow  
start stands in relation to that, and where high-speed mechanisms  
stand in relation to that. Or should use an even simpler equation?

Do we even need or want such a metric?

Cheers,
Michael

From: [email-masked] (Thomas Dreibholz)
Date: Sat Jul  2 20:28:44 2011
Subject: [Iccrg] Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support
Message-ID: <[email-masked]>

CALL FOR PAPERS

2nd International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS 2012)
In conjunction with the 26th IEEE International Conference on Advanced 
Information Networkingand Applications (AINA 2012)
Fukuoka, Japan, March 26-29, 2012
http://tdrwww.iem.uni-due.de/pams2012.html

The intent of our workshop is to bring together people from research and
industry, in order to provide a discussion forum for state-of-the-art topics
related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session
(with short presentations) to introduce preliminary ideas as well as work in
progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimization for Multi-Homed Systems
    * Multi-Homing in the Context of Future Internet

GENERAL CHAIRS:

    * Thomas Dreibholz, University of Duisburg-Essen, Germany
    * Martin Becke, University of Duisburg-Essen, Germany

PROGRAM CHAIRS:

    * Michael T?xen, M?nster University of Applied Sciences, Germany
    * Erwin P. Rathgeb, University of Duisburg-Essen, Germany

PROGRAM COMMITTEE

    * Hakim Adhari, University of Duisburg-Essen, Germany
    * Nicola Altan, Cetekom, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Anna Brunstr?m, Karlstad University, Sweden
    * Glenford Mapp, Middlesex University, United Kingdom
    * Michio Honda, Keio University, Japan
    * Seok J. Koh, Kyungpook National University, Korea
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, University of British Columbia, Canada
    * Irene R?ngeler, M?nster University of Applied Sciences, Germany
    * Robin Seggelmann, M?nster University of Applied Sciences, Germany
    * Esbold Unurkhaan, Mongolian University of Science and Technology, 
Mongolia
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway

IMPORTANT DATES

    * Paper Submission Deadline:       October 01, 2011
    * Author Notification:             December 01, 2011
    * Camera-Ready Paper Submission:   January 06, 2012

CONTACT

For further information, please contact:

    * Thomas Dreibholz (dreibh AT iem.uni-due.de)
    * Martin Becke (martin.becke AT uni-due.de)

WEBSITE

http://tdrwww.iem.uni-due.de/pams2012.html