Subject: [Iccrg] Re: I-D ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.tx t
From: [email-masked] (Bob Briscoe)
Date: Fri May 30 18:40:16 2008

Michael,

At 15:02 27/05/2008, Michael Scharf wrote:
>On Fri, 23 May 2008 at 02:46:40, Bob Briscoe wrote:
> >>  3.1.1 Performance and robustness
> >>  ...
> >>     - What is the minimum support that is needed from routers in order
> >>      to achieve significantly better performance than with end-to-end
> >>      mechanisms?
> >>
> >> BC: Can you add the obvious: without damaging the end-to-end principle.
> >
> > I'd certainly agree to that. Co-authors?
[snip]
>For instance, [1] concludes that "congestion control is one
>function that is not well suited to end-to-end implementation."  I
>guess that not everyone will agree to this statement.

I for one disagree...

>Deepening this discussion is propably beyond the scope of this
>draft. But I could imagine to add one or two references that reflect
>the discussions concerning the implication on the e2e principle.
>
>Can anyone recommend relevant references other than [1]?

Richard J. Gibbens and Frank P. Kelly, "Resource pricing and the 
evolution of congestion control" Automatica 35 (12) pp. 1969--1985 
(December, 1999).

And... I guess our work to police e2e congestion control building on 
Kelly but with engineering rather than pricing. But I guess 
self-citations aren't allowed ;)

Bob

>Michael
>
>
>[1] T. Moors: "A critical review of "End-to-end arguments in system
>design"", Proc. International Conference on Communications (ICC), 2002

____________________________________________________________________________
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] (Bob Briscoe)
Date: Fri May 30 18:33:31 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Brian,

At 04:06 27/05/2008, Brian E Carpenter wrote:
>...
> >> BC: Is there also a question of how to distinguish corruption affecting
> >> a single stream from corruption affecting multiple streams?
> >
> > Do you mean multiple streams with a common endpoint, or independent
> > endpoints?
> >
> > You obviosuly have something in mind. I can't see why you'd need to do
> > this, unless there was someting you could do different in each case.
>
>Since we're presumbly discussing endpoint behavior, I was thinking of the
>case where multiple streams from or to the same endpoint are all experiencing
>corruption simultaneously. That fact obviously has diagnostic value
>since it says that the corruption is occurring near the endpoint.
>I'm not sure the transport layer can do much with it, but it might
>be a useful indication for a lower layer (e.g. a hint to drop the bit
>rate on a wireless interface). You might feel this is out of scope...

Not quite OOS, but pretty close to OOS.

>...
> >
> > [Added while re-sending posting:]
> > The position paper I have in the IETF p2p infrastructure workshop on Wed
> > outlines an interesting equivalence between using Diffserv to do a
> > background class and using weighted endpoint congestion control to do
> > weighted sharing. It briefly explores the practical deployment issues of
> > each.
> >
> > "Solving this traffic management problem... and the next, and the next"
> > <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>
> > (3pp)
>
>Yes, that's an interesting point. But the risk of people "cheating"
>is real, so I don't see some form of inspection-based policing
>going away.

For such policing we've defined what we believe is necessary and 
sufficient in a self-contained datagram to ensure transports will 
respond sufficiently to congestion without per-flow processing, with:
- minimal harm to evolvability (e2e principle)
- minimal constraint on user freedom

Our proposal needs the last available bit in IPv4 to achieve 
practical policeability.

That's been my and my team's research for the last 11 years (the 
above link tries to summarise the insights without pushing our 
particular solution).

For the specifics, see our project page:
<http://www.cs.ucl.ac.uk/staff/bbriscoe/projects/refb/>

Bob

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

From: [email-masked] (Michael Welzl)
Date: Wed May 28 12:59:27 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.tx t
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

hi all,

terribly sorry for being silent for such a long time - i actually
took a holiday!  :-)

since i'm trying to catch up - if you need me to comment on anything
particular, let me know, otherwise i'll just monitor the discussion
as it proceeds...

for this:

> Can anyone recommend relevant references other than [1]?
> 
> Michael
> 
> 
> [1] T. Moors: "A critical review of "End-to-end arguments in system
> design"", Proc. International Conference on Communications (ICC), 2002

yes, i can. there's a (IMO) great discussion of the e2e argument in
the Joe Touch / James Sterbenz book:
"High-Speed Networking: A Systematic Approach to High-Bandwidth Low
Latency Communication"
Wiley, 2001

David Reed also has some things on his website, at
http://www.reed.com/dpr/ under "papers" and "thoughts",
respectively

cheers
michael

From: [email-masked] (Michael Scharf)
Date: Tue May 27 14:46:46 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.tx t
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 23 May 2008 at 02:46:40, Bob Briscoe wrote:
>>  3.1.1 Performance and robustness
>>  ...
>>     - What is the minimum support that is needed from routers in order
>>      to achieve significantly better performance than with end-to-end
>>      mechanisms?
>>
>> BC: Can you add the obvious: without damaging the end-to-end principle.
>
> I'd certainly agree to that. Co-authors?

The draft mentions the end-to-end principle in earlier sections, but
not explicitly in section 3.1. From the context it is clear that there
are implications. But, true, there should be an explicit statement
that router-supported congestion control may interfere with the e2e
principle.

However, this seems to raise some rather philosophical questions. The
applicabiliy of the e2e principle to congestion control has already
been discussed extensively, and this is apparently not a trivial
issue. For instance, [1] concludes that "congestion control is one
function that is not well suited to end-to-end implementation."  I
guess that not everyone will agree to this statement.

Deepening this discussion is propably beyond the scope of this
draft. But I could imagine to add one or two references that reflect
the discussions concerning the implication on the e2e principle.

Can anyone recommend relevant references other than [1]?

Michael

[1] T. Moors: "A critical review of "End-to-end arguments in system
design"", Proc. International Conference on Communications (ICC), 2002

From: [email-masked] (Kashif Munir)
Date: Tue May 27 12:31:53 2008
Subject: [Iccrg] A review of the CUBIC draft
In-Reply-To: <[email-masked]>
References: <002201c8bf3b$24d36ab0$d0f5e88a@DCXMWG81> <[email-masked]>
Message-ID: <001501c8bfef$7e84cae0$3340a8c0@DCXMWG81>

Dear Lachlan,

Thanks for the comments. Basically, I am asked to comment on two things.

One of them is the protocol's impact on competing flows. I believe, it is
"mainly" about the protocol's fairness to standard TCP in difficult and
typical scenarios (like those mentioned in your paper "Towards a Common TCP
Evaluation Suite"). It can only be a relative comparison and by seeing the
results in the draft and in the CUBIC related papers, it is shown to behave
relatively less aggressive to the standard TCP flows (in other words more
TCP friendly) than some of the other high speed protocols. However, it is
one of the metrics that must be considered along with other metrics. In the
case of the networks having more loss rate, the performance of CUBIC is no
worse than that of standard TCP and relatively less aggressive to standard
TCP than some of the other variants. 

Although the authors mention that in the case of wireless networks, CUBIC's
performance is no worse than that of regular TCP; it would be interesting to
see some results showing its impact on competing flows in that sort of
environments.

Regarding RTT-fairness, I agree that there is no point in calling a protocol
as RTT-fair if it is just for the exceptional case when all RTTs are equal.
The CUBIC draft does explain it on page numbers 3, 4 and 13 of the draft.
However, the explanation may further be refined. For example, on page 13 of
the draft it is mentioned, "CUBIC ensures convergence of competing CUBIC
flows in he same bottleneck links to an equal bandwidth share. When
competing flows have different RTTs, their bandwidth shares are linearly
proportional to the inverse of their RTT ratios." If I have understood
correctly, the sentences are contradicting. It is possible that two flows
having different RTTs sharing a same bottleneck link. According to the first
sentence both flows would share the bandwidth equally but according to the
second they would not. I would not say that this is not strength of the
protocol as according to the RFC 5166 (Metrics for the Evaluation of
Congestion Control Mechanisms), a congestion control mechanism should be
evaluated in terms of trade-offs between a range of metrics and not just
only for a single metric.  

Best Regards,
Kashif Munir
-------------------
PhD Candidate
Institute of Computer Science
University of Innsbruck, Austria
Homepage: http://dps.uibk.ac.at/~kashif/

 
 
-----Original Message-----
From: Lachlan Andrew [mailto:[email-masked]] 
Sent: Monday, May 26, 2008 8:00 PM
To: Kashif Munir
Cc: iccrg
Subject: Re: [Iccrg] A review of the CUBIC draft

Greetings Kashif,

Thanks for the review.

2008/5/26 Kashif Munir <[email-masked]>:
> The CUBIC protocol can be considered safe for
> deployment as it does not perform worse than TCP in difficult environments
> like wireless networks.

My understanding was that being "safe" is normally about the
algorithm's impact on *competing* flows, rather than its own
performance.  Could you please comment on how well other flows fare in
difficult (and typical) environments when CUBIC is used?

> the explanation must be clear
> and consistent throughout the document. It must be clearly specified that
> the CUBIC flows are only RTT-fair when they have same RTT

What does RTT fairness mean if all RTTs are equal?

> and by taking some
> time for convergence to fair share otherwise the CUBIC flows have their
> bandwidth shares linearly proportional to the inverse of their RTT ratio.

Good.  That is more RTT fair than Reno.

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan

From: [email-masked] (Kashif Munir)
Date: Mon May 26 15:01:14 2008
Subject: [Iccrg] A review of the CUBIC draft
Message-ID: <002201c8bf3b$24d36ab0$d0f5e88a@DCXMWG81>

Hi all,

I have read the CUBIC draft and have seen the extensive simulations and
experimental results related to CUBIC on the authors' pages. Here are my
comments and suggestions about it.

The language of the CUBIC draft is simple and clear. The draft almost
completely follows the guidelines for specifying the new congestion control
algorithms [RFC 5033]. The CUBIC protocol can be considered safe for
deployment as it does not perform worse than TCP in difficult environments
like wireless networks. I believe it should be published as an experimental
RFC. 

I have a few suggestions that may possibly improve the quality of the draft.

-   The draft must include an explanation on why the value of C (the CUBIC
parameter) is taken equal to 0.4. The CUBIC paper does not discuss it
either.

-   Regarding RTT-fairness among CUBIC flows, the explanation must be clear
and consistent throughout the document. It must be clearly specified that
the CUBIC flows are only RTT-fair when they have same RTT and by taking some
time for convergence to fair share otherwise the CUBIC flows have their
bandwidth shares linearly proportional to the inverse of their RTT ratio.

-   The authors must explain in the draft about the assumption, "we believe
that under wired Internet, use of the linear share notion seems more
reasonable than equal share or a higher order shares".

 

Best Regards

Kashif Munir

-------------------

PhD Candidate
Institute of Computer Science
University of Innsbruck, Austria
Homepage: http://dps.uibk.ac.at/~kashif/

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080526/0d61e305/attachment.html
>From [email-masked]  Mon May 26 18:59:45 2008
From: [email-masked] (Lachlan Andrew)
Date: Mon May 26 18:43:59 2008
Subject: [Iccrg] A review of the CUBIC draft
In-Reply-To: <002201c8bf3b$24d36ab0$d0f5e88a@DCXMWG81>
References: <002201c8bf3b$24d36ab0$d0f5e88a@DCXMWG81>
Message-ID: <[email-masked]>

Greetings Kashif,

Thanks for the review.

2008/5/26 Kashif Munir <[email-masked]>:
> The CUBIC protocol can be considered safe for
> deployment as it does not perform worse than TCP in difficult environments
> like wireless networks.

My understanding was that being "safe" is normally about the
algorithm's impact on *competing* flows, rather than its own
performance.  Could you please comment on how well other flows fare in
difficult (and typical) environments when CUBIC is used?

> the explanation must be clear
> and consistent throughout the document. It must be clearly specified that
> the CUBIC flows are only RTT-fair when they have same RTT

What does RTT fairness mean if all RTTs are equal?

> and by taking some
> time for convergence to fair share otherwise the CUBIC flows have their
> bandwidth shares linearly proportional to the inverse of their RTT ratio.

Good.  That is more RTT fair than Reno.

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan

From: [email-masked] (Bob Briscoe)
Date: Sun May 25 21:00:15 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.txt
Message-ID: <[email-masked]>

Brian,

[sending again, now I've subscribed the different @ I was sending 
from to the cc'd list. I've also added another comment so pls read 
this one, not the last.]

Tx for comments. SOrry for lack of previous response (I'm having big 
SMTP relay problems - might have been the cause)

inline...

At 03:13 21/05/2008, Brian E Carpenter wrote:
>I didn't see a reply to my initial questions, but below
>are my comments on the draft as a whole (which I found quite
>thought-provoking, so thankyou!).
>
>On 2008-04-29 11:11, Brian E Carpenter wrote:
> > Hi,
> >
> > I'm reading your draft with interest but have two questions
> > before I start commenting...
> >
> > 1. Are there references for the assertion in section 3.3
> > that "most congestion seen on today's Internet is due to
> > an excess of bits rather than packets"? I have to say
> > I found this surprising and I'm curious about the evidence.

In my talk to the ICCRG about [Bri08], I said I couldn't find any 
actual paper studies. But Larry Dunn said people who designed router 
hardware worked on the design goal of handling a run of the smallest 
possible packets. Nonetheless the law of economic compromises drives 
them to not quite achieve this, because they can make the performance 
stats look better by designing for a more typical packet mix, and 
buffering up runs of small packets to a certain degree.

So this suggests that routers will only get into packet congestion 
problems when there are long runs of minimum size packets (acks or 
DoS), but normally they will be operating under bit congestion on the 
output interfaces, rather than packet congestion on the inputs.

Does this ring true now it's said with a little more longhand 
background? If you have any contrary evidence, it would be great (tho 
problematic in terms of further cc issues).

> >
> > 2. There are citations later in section 3.3 of [Bri08] but
> > there is no such reference listed. Is that meant to be [Bri07],
> > [Bri06], or something else?
> >

Answer is 'Something else'
- whoops - it was missing from refs:

Byte and Packet Congestion Notification
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>

>  3.1.1 Performance and robustness
>  ...
>     - What is the minimum support that is needed from routers in order
>      to achieve significantly better performance than with end-to-end
>      mechanisms?
>
>BC: Can you add the obvious: without damaging the end-to-end principle.

I'd certainly agree to that. Co-authors?

>  3.2 Challenge 2: Corruption Loss
>  ...
>    Open questions concerning corruption loss include:
>
>    - How should corruption loss be detected?
>
>    - How should a source react when it is known that corruption has
>      occurred?
>
>BC: Is there also a question of how to distinguish corruption affecting
>a single stream from corruption affecting multiple streams?

Do you mean multiple streams with a common endpoint, or independent endpoints?

You obviosuly have something in mind. I can't see why you'd need to 
do this, unless there was someting you could do different in each case.

>  3.3 Challenge 3: Small Packets
>  ...
>    o) Confusable Causes of Drop
>
>    There is a considerable body of research on how to distinguish
>    whether packet drops are due to transmission corruption or to
>    congestion. But the full list of confusable causes of drop is longer
>    and includes transmission loss, congestion loss (bit congestion and
>    packet congestion), and policing loss
>
>BC: Wouldn't the impact of some kind of QOS support belong here, more
>generally than "policing"? Certainly if diffserv queue management is
>in place, you'll see differential drop behaviors.

Altho that's a valid point, I think it's orthogonal to the issue 
here, which was: "What should I (the transport) do if I see a drop? 
And is there anything we as protcol designers can do to distinguish 
between different sorts of drop so transports don't have to act based 
on the most pessimistic assumption?"

In the Diffserv case, the differential drop is predicated on an 
assumption that endpoints will respond the same to one drop, whatever 
the class it's from. So dropping more not only differentiates service 
delivery, but will probably leverage standard congestion response 
(e.g. TCP) behaviours to considerably inflate the differentiation.

But see discussion on Gibbens paper below.

>  3.6 Challenge 6: Precedence for Elastic Traffic
>  ...
>    The preferential treatment of higher precedence traffic with
>    appropriate congestion control mechanisms is still an open issue that
>    may, depending on the proposed solution, impact both the host and the
>    network precedence awareness, and thereby congestion control.
>
>    TODO:
>    - Discuss existing work on low-priority flows - why isn't this stuff
>    used? That's an open issue, interesting things could be done with it!

[Added while re-sending posting:]
The position paper I have in the IETF p2p infrastructure workshop on 
Wed outlines an interesting equivalence between using Diffserv to do 
a background class and using weighted endpoint congestion control to 
do weighted sharing. It briefly explores the practical deployment 
issues of each.

"Solving this traffic management problem... and the next, and the next"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>
(3pp)

>BC: Well, good question. Maybe the authors of RFC 3662 have ideas.
>Internet2 experimented with a scavenger service, too, although
>that seems to have faded some years ago.
>http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt
>
>    - Discuss DiffServ [RFC2474] [RFC2475] related aspects with
>    congestion control.
>
>BC: In diffserv we sort of assumed this was orthogonal, i.e. would
>be an end to end issue. But (as noted above) there will be
>different dropping disciplines for different traffic classes.

Yes, e.g preferential drop of EF/AF etc, Pre Congestion Notification (PCN) etc.

>There is scope for new thinking there.

Certainly. There's an interesting point of view that says (when ECN 
is supported rather than drop) that higher priority traffic should 
see higher ECN marking not lower. Reflecting the sum of the lengths 
of the queue for the traffic's own class and all the other queue(s) 
backed up behind it.

See
Richard J. Gibbens and Frank P. Kelly, "On Packet Marking at Priority 
Queues,"  IEEE Transactions on Automatic Control 47 (6) pp. 
1016--1020 (June, 2002).

This comes from a world where fairness is determined by limiting the 
amount of congestion marking you can cause, because it reflects the 
actual congestion you are causing to all classes, not just your own. 
Of course, it is also predicated on a world where you are allowed 
weighted response to congestion (so if you choose a high weight, you 
respond less to the same level of congestion as others with a lower 
weight congestion control).

>I should point out that diffserv turned the RFC791 notion of
>"precedence" into a multidimensional notion; traffic classes
>can have several properties which are almost orthogonal
>to each other. Precedence is a very simple-minded way to share
>resources.

Yup - we should fix this terminology.

Cheers

Bob

>Regards
>      Brian

____________________________________________________________________________
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] (Lachlan Andrew)
Date: Wed May 14 18:59:05 2008
Subject: [Iccrg] Heresy following "TCP: Train-wreck"
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Bob,

2008/5/14 Bob Briscoe <[email-masked]>:
> At 19:40 08/04/2008, Lachlan Andrew wrote:
>> The key is that the quantity you are both sharing out (however you do
>> it) is  *congestion*  rather than rate or volume.
>
> True, but even we agree it should be possible to make transports accountable
> for causing congestion, this consensus on the _metric_ would lead very much
> into a knock-on _protocol_ issue:
> "However you do it" is no good if there are zero pratical ways to do it.

Agreed.  The "however you do it" referred to whether you cap
congestion or charge (senders) for it.  I don't see how that is a
protocol issue.  It is a billing + admission control issue, with both
options needing the same information at the network ingress.

Both options need IP changes, but I believe that the same changes
would suffice in each case.  Correct me if I'm wrong.

> But networks can't cap the amount of congestion a receiver receives. It's
> too late by then.

Why not?  If all packets are dropped after the congestion cap is met,
then the user will not be able to open any TCP sessions (or SIP, or
...), and so there will be no traffic.  Even most existing sessions
will time out due to lack of ACKs.

> Currently networks can only charge for ECN received
...
> 'denial of funds' attacks.
> Hence the need for a protocol to make _senders_ accountable for causing
> congestion. That's a really hard protocol problem.

Absolutely.  I'm all for re-ECN.  I just don't see a big difference in
the data-plane signalling needed for charging (of senders) versus
capping.  Obviously management plane signalling will be different, but
that is easy once changes to IP have been agreed on.

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan

From: [email-masked] (Bob Briscoe)
Date: Wed May 14 11:41:01 2008
Subject: [Iccrg] Heresy following "TCP: Train-wreck"
In-Reply-To: <[email-masked] >
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lachlan,

Realised I never replied to this (catching up on old emails)...

At 19:40 08/04/2008, Lachlan Andrew wrote:
>Greetings Bob,
>
>On 08/04/2008, Bob Briscoe <[email-masked]> wrote:
> >  Just to be clear - we're not proposing charging for congestion like Kelly.
> >  It's an important difference. Like the difference between volume charging
> > and volume capping.
>
>I didn't mean to misrepresent you, but to me, that's an IETF-level
>"implementation detail", rather than an IRTF-level issue.  To be
>maximally useful, it should be something which affects the
>users'/applications' behaviour to avoid peak times.
>
>The key is that the quantity you are both sharing out (however you do
>it) is  *congestion*  rather than rate or volume.

True, but even we agree it should be possible to make transports 
accountable for causing congestion, this consensus on the _metric_ 
would lead very much into a knock-on _protocol_ issue:
"However you do it" is no good if there are zero pratical ways to do it.

The IRTF can't propose a metric for networks to arbitrate between 
users if networks can't see the metric (given current Internet protocols)...

The Internet was designed so only endpoints could see congestion - 
it's really hard for the network to intercept congestion feedback 
robustly. And if networks do use the feedback, it will just encourage 
receivers not to send feedback.

ECN helps, but even them, networks can only make receivers 
accountable for the congestion sent to them. Even with ECN, networks 
can't see congestion up ahead when accepting packets from the sender.

But networks can't cap the amount of congestion a receiver receives. 
It's too late by then. Currently networks can only charge for ECN 
received (as Kelly suggested). At first sight that looks like it 
creates the right incentives, but I don't believe the IRTF should 
propose something that _requires_ a very specific business model. 
Plus it would just lead to 'denial of funds' attacks.

Hence the need for a protocol to make _senders_ accountable for 
causing congestion. That's a really hard protocol problem.

> >  Finally, I don't think 'we' have to use WFQ as an interim solution -
> > fortunately 'we' don't make that choice - operators have protected a better
> > form of fairness than TCP's on the Internet with WFQ for many years.
>
>OK, but "we" have the choice of letting loose algorithms which will
>increase pressure to deploy it where it isn't already enabled, don't
>we?

True.

Bob

>Cheers,
>Lachlan
>
>--
>Lachlan Andrew  Dept of Computer Science, Caltech
>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
>http://netlab.caltech.edu/lachlan

____________________________________________________________________________
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: Thu May  1 13:24:29 2008
Subject: [Iccrg] Soliciting reviews for HTCP
Message-ID: <004c01c8ab88$3643bcd0$0200a8c0@fun>

Dear all,

We are still looking for volunteers to provide a review of
the HTCP draft. The material is at:
http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_htcp

Cheers,
Michael