Subject: [Tsvwg] terminology issues in draft-floyd-tsvwg-besteffort

From: Bob Briscoe <[email-masked]>
Date: Sun, 22 Jul 2007 20:05:11 +0100

Mark, Sally,

Before I went off-list for a holiday over the last couple of weeks, I said 
I generally agreed with <draft-floyd-tsvwg-besteffort-00.txt>
but I had issues with some choices of terminology. Can I ask you to 
consider the following changes to help the debate be more precise.
But, before I start, I just want to emphasise that I agree that it is 
important for people to understand that:
- ECN is not as simple as drop
- policing bulk congestion is not as simple as no policing at all and
- measuring bulk congestion for border SLAs is not as simple as not having 
border SLAs.
Or more succinctly: enforcing fairness is not as simple as not enforcing 
fairness (which is pretty obvious).

1/ Simple?

The term 'Simple Best Effort' contains a value judgement about simplicity.

Many ISPs already limit their heavy users using various metrics: Volume 
caps, volume pricing, deep packet inspection (=infering an app implies 
heavy usage), or vaguely worded acceptable use policies tied to various 
forms of monitoring that allow them to issue email warnings, reduce 
priority and/or issue disconnection notices.

By saying that 'Simple BE' is the dominant traffic class in the current 
Internet, you are either discounting all this policing as "not really 
policing" or as "not really complex", or you are implying most ISPs don't 
do any of this or most ISPs aren't planning to do more of this.

What we're trying to do is provide the simplest possible principled and 
effective policing metric that is application-neutral and user-neutral; as 
an alternative to all the kludges being introduced that are complex and/or 
too blunt and/or non-neutral. It's most disheartening to be accused of 
making the world more complex, when we believe we're making it simpler than 
it would otherwise be.

The best way to avoid that value judgement altogether is to just say 
"non-policed" or "unlimited", which is what you actually mean. And it would 
be best not to claim (without evidence) that ISPs who don't do any limiting 
are still predominant.

2/ BE?

This resource allocation debate is not about policing solely BE scheduled 
traffic. It could just as easily be about policing AF (say). The core issue 
that concerns you is whether ECN has to be turned on or not, so the most 
precise term is surely "non-ECN".

Points 1/ & 2/ summarised: Something like "Unlimited Non-ECN" would be more 
precise and preferable to 'Simple BE'.

---
I also have three strong disagreements that might be just terminology, or 
might be misunderstandings of what we're proposing. All three are in areas 
where we have deliberately wanted to allow vendors and ISPs to come up with 
a range of solutions, which might explain your confusion. But it would be 
fairer on our proposal if it was judged on the set of these 3 choices that 
is both the simplest and still fully effective. The choices you have chosen 
to hilite are the ones we specifically do not recommend - the most complex 
and/or least acceptable.

It's tough on us to be accused of adding complexity when what we'd 
recommend is actually as pretty d@mn simple as enforcing fairness can get.

3/ User pricing: Flat monthly (in our simplest effective proposal).

Please don't imply we're advocating user congestion pricing, given the 
whole reason we brought re-ECN to the IETF back in 2005 was because we 
found a way to limit congestion without constraining how operators price 
their services to their customers. Specifically, re-ECN is designed to work 
with flat monthly pricing.

4/ User policing: Bulk per-customer (in our simplest effective proposal).

Please don't imply that we're advocating per-flow policing. Admittedly we 
have always shown how you could do either per-flow or per-user. Before 
Oct-06 when I wrote that I-D on dismantling flow rate fairness, the 
community wanted to be able to police flow rates, so we wanted to show we 
could. But we neither require it nor recommend it. Our per-user policing 
makes per-flow policing redundant (but it's still there if an IPS wants it).

For the avoidance of doubt, "Bulk per-customer" policing means policing all 
traffic crossing the customer's sending access interface using a bulk token 
bucket to regulate the bit rate of congestion marked packets to all 
destinations together.

5/ Economic infrastructure: Simple pair-wise relationships (in our simplest 
proposal)

Please don't imply we're making economic infrastructure more complex. All 
network layer relationships would still be between directly connected 
neighbours (pairwise).

Currently many border contracts between privately connected ISPs or between 
ISPs and a peering exchange include an element of usage charging (as well 
as interface capacity pricing). Whether based on volume, on some notion of 
peak demand, or on a hybrid. We propose adding a metric (congestion volume) 
that is only slightly less simple than monthly byte-volume.

However, congestion volume is much more effective, as it can be used to 
make networks precisely accountable for the costs they cause in other 
networks (unlike a volume metric, which depresses usage even when the 
capacity is there for it).

So most of the inter-domain contracts that currently include an element of 
usage might switch to using congestion volume. And those that don't include 
any form of usage measurements in their contracts might stick that way. 
That doesn't make any contracts any more complex.

Bob

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

---

From: Sally Floyd <[email-masked]>
Date: Tue, 24 Jul 2007 10:01:17 -0700

Bob -

I am answering the email one item at a time, as I find time.

> Many ISPs already limit their heavy users using various metrics: 
> Volume caps, volume pricing, deep packet inspection (=infering an app 
> implies heavy usage), or vaguely worded acceptable use policies tied 
> to various forms of monitoring that allow them to issue email 
> warnings, reduce priority and/or issue disconnection notices.
>
> By saying that 'Simple BE' is the dominant traffic class in the 
> current Internet, you are either discounting all this policing as "not 
> really policing" or as "not really complex", or you are implying most 
> ISPs don't do any of this or most ISPs aren't planning to do more of 
> this.
>
> What we're trying to do is provide the simplest possible principled 
> and effective policing metric that is application-neutral and 
> user-neutral; as an alternative to all the kludges being introduced 
> that are complex and/or too blunt and/or non-neutral. It's most 
> disheartening to be accused of making the world more complex, when we 
> believe we're making it simpler than it would otherwise be.
>
> "non-policed" or "unlimited", which is what you actually mean. And it 
> would be best not to claim (without evidence) that ISPs who don't do 
> any limiting are still predominant.

We defined the phrase "simple best effort" as follows:
In the abstract:
    "This document presents some observations on "simple best-effort"
     traffic, defined loosely for the purposes of this document as
     Internet traffic that is not covered by Quality of Service
     mechanisms, congestion-based pricing, or the like."

And later in the Introduction:
    "For the purposes of this document, we define "simple
    best-effort traffic" as traffic that does not *rely* on the
    *differential treatment* of flows either in routers or in policers,
    enforcers, or other middleboxes along the path."

I am happy to clarify the definition of "simple best effort" as
used in our draft to say that it can include a wide range of things
done by ISPs, including volume caps, volume pricing, deep packet
inspection, vaguely worded acceptable use policies tied to various
forms of monitoring, and other things done by ISPs.  But not including
traffic that uses diffserv, intserv, congestion-based pricing,
cost-based fairness mechanisms, *requirements* for ECN enabled at
congested routers coupled with policers at the two ends of the
connection, etc.

I will also try to clarify the definition to make it clear that,
for the purposes of this document, we are using the phrase "simple
best-effort traffic" to mean "best-effort traffic like most of the
traffic in the current Internet today".  We *don't* mean "non-policed",
or "unlimited".

We are not trying to imply that moving packets from point A to point
B is simple, with or without volume caps, volume pricing, deep
packet inspection, vaguely worded acceptable use policies tied to
various forms of monitoring.

> 2/ BE?
>
> This resource allocation debate is not about policing solely BE 
> scheduled traffic. It could just as easily be about policing AF (say). 
> The core issue that concerns you is whether ECN has to be turned on or 
> not, so the most precise term is surely "non-ECN".

I understand that the resource allocation debate is not about
policing solely BE scheduled traffic.  As I said in the introduction
to this draft, "This document does not attempt to be a rebuttal to
[B07], or to answer any or all of the issues raised in [B07]".  This
document is specifically about best-effort traffic, as it tries to
make clear.

"Non-ECN" was not what I had in mind.  I will clarify the definition
of "simple best effort traffic" to say that it can include ECN.
And that traffic that does not quality as "simple best-effort
traffic", for the definition used in this draft, might or might not
use ECN (e.g, diffserv traffic).

But I am not going to try for an exhaustive definition of "simple
best-effort traffic".  I think I can make the points in the draft,
for most readers, without that.

> Points 1/ & 2/ summarised: Something like "Unlimited Non-ECN" would be 
> more precise and preferable to 'Simple BE'.

As I explained above, that is not what I had in mind.
As I said above, I will clarify our definition of
simple best-effort traffic.

- Sally
http://www.icir.org/floyd/
http://tools.ietf.org/html/draft-floyd-tsvwg-besteffort-00

---

From: Sally Floyd <[email-masked]>
Date: Tue, 24 Jul 2007 10:16:51 -0700

> found a way to limit congestion without constraining how operators 
> price their services to their customers. Specifically, re-ECN is 
> designed to work with flat monthly pricing.

This draft is not about re-ECN.  It is about the usefulness of
"simple best-effort traffic", and the usefulness of flow-rate fairness
for simple best-effort traffic.

This draft is not about the presence or absence of flat monthly
pricing for users.  One could have flat monthly pricing with no
other limitations, one could have flat monthly pricing with volume
limits, or one could have flat monthly pricing with some form of
"you get what you pay for".  The first two forms don't result in
"rich" users getting all of the bandwidth in times of high congestion
(e.g., after the earthquake).  The third form easily could.  E.g.,
if all of the traffic was "you get what you pay for", even with
flat monthly fees, then it could be really expensive to send packets
in the time interval after the earthquake, or some other 
highly-congested
period, and only the rich would be able to send packets.  I would
be opposed to setting such a "you get what you pay for" goal as the
overriding goal for the global Internet, with or without flat monthly
fees.

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Tue, 24 Jul 2007 10:29:11 -0700

Bob -

> Please don't imply that we're advocating per-flow policing. Admittedly 
> we have always shown how you could do either per-flow or per-user. 
> Before Oct-06 when I wrote that I-D on dismantling flow rate fairness, 
> the community wanted to be able to police flow rates, so we wanted to 
> show we could. But we neither require it nor recommend it. Our 
> per-user policing makes per-flow policing redundant (but it's still 
> there if an IPS wants it).
>
> For the avoidance of doubt, "Bulk per-customer" policing means 
> policing all traffic crossing the customer's sending access interface 
> using a bulk token bucket to regulate the bit rate of congestion 
> marked packets to all destinations together.

If you let me know where the draft implied that you were
advocating per-flow policing, I would be happy to correct it.
(I looked, but I didn't see it.)

The draft is not intended to be about any specific proposed mechanism.
It is simply in support of "simple best-effort traffic", and in support 
of
flow-based fairness for simple best-effort traffic.

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Tue, 24 Jul 2007 10:43:35 -0700

> 5/ Economic infrastructure: Simple pair-wise relationships (in our 
> simplest proposal)
>
> Please don't imply we're making economic infrastructure more complex. 
> All network layer relationships would still be between directly 
> connected neighbours (pairwise).
>
> Currently many border contracts between privately connected ISPs or 
> between ISPs and a peering exchange include an element of usage 
> charging (as well as interface capacity pricing). Whether based on 
> volume, on some notion of peak demand, or on a hybrid. We propose 
> adding a metric (congestion volume) that is only slightly less simple 
> than monthly byte-volume.
>
> However, congestion volume is much more effective, as it can be used 
> to make networks precisely accountable for the costs they cause in 
> other networks (unlike a volume metric, which depresses usage even 
> when the capacity is there for it).
>
> So most of the inter-domain contracts that currently include an 
> element of usage might switch to using congestion volume. And those 
> that don't include any form of usage measurements in their contracts 
> might stick that way. That doesn't make any contracts any more 
> complex.

Our draft says the following:

    "The difficulties of deployment for end-to-end intserv or diffserv
    mechanisms are well-known, having in part to do with the difficulties
    of deployment for the economic infrastructure that would be needed
    [B03].  It seems likely that cost-based pricing based on re-ECN could
    also have a difficult deployment path, involving the deployment of
    ECN-marking at routers, policers at both ends of a connection, and a
    complex set of economic relationships [B07]."

I would be happy to clarify it that the set of economic relationships
required for "cost-based pricing based on re-ECN" would be pairwise,
with a metric for congestion volume.

(Note that this sentence is not about all possible forms of re-ECN,
but about "cost-based pricing based on re-ECN".  Our draft is not
about re-ECN - it is simply in support of "simple best-effort
traffic", and in support of flow-based fairness for simple best-effort
traffic.)

- Sally

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Jul 2007 13:05:09 +0100

Sally,

At 18:01 24/07/2007, Sally Floyd wrote:
>>effective policing metric that is application-neutral and user-neutral; 
>>as an alternative to all the kludges being introduced that are complex 
>>and/or too blunt and/or non-neutral. It's most disheartening to be 
>>accused of making the world more complex, when we believe we're making it 
>>simpler than it would otherwise be.
>>
>>would be best not to claim (without evidence) that ISPs who don't do any 
>>limiting are still predominant.
>

Then I don't see the point of the draft. You are saying "simple" traffic is 
useful because it is simple, even though you are willing to include all the 
non-simple things that need to be done to limit this traffic - so it isn't 
actually simple.

Now you've clarified your definition, I really don't know what the purpose 
of this draft is. It makes little sense with this new definition of simple 
to include non-simple.

>>traffic. It could just as easily be about policing AF (say). The core 
>>issue that concerns you is whether ECN has to be turned on or not, so the 
>>most precise term is surely "non-ECN".
>

OK, fair enough - you're allowed to confine your own scope to BE and that's 
a v relevant thing to focus on.

>simple best-effort traffic.

So it's down to this question of simple including non-simple.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Jul 2007 13:23:46 +0100

Sally,

At 18:16 24/07/2007, Sally Floyd wrote:
>>their services to their customers. Specifically, re-ECN is designed to 
>>work with flat monthly pricing.
>
>in the time interval after the earthquake, or some other highly-congested

I know. It's distasteful to me to (I am a life-long socialist). But the 
alternatives are worse. I have thought about this long and hard.

On the demand side: If the rich don't get to be able to buy the right to 
use capacity, the alternative is that the malicious and selfish get to 
drive out those trying to be sociable in their use of the Internet. And 
that's for always, not just during earthquakes. Also, the lack of any 
resource sharing arbitration will lead to a vacuum that will be filled by 
the rich and powerful (which is what deep packet inspection represents - 
those with power and influence controlling what can and can't be done on 
the Internet).

On the supply side: The malicious and selfish will use the Internet 
excessively, but not pay their share, so there won't be sufficient 
incentives for anyone to invest in more capacity for those of us who want 
to use the Internet responsibly.

In summary, a knee-jerk reaction against a market mechanism needs to be 
tempered by the thought of what will otherwise fill the vacuum - the lesson 
of the Soviet Union?

However, you will notice in my draft on fairness (and in my design of 
re-ECN) that I have been careful to enable more equitable resource 
allocation schemes locally. This can give _true_ equality, whereas flow 
rate equality is just a license for the selfish and malicious to take what 
they want.

Overall, I put my hands up and admit it: we don't have a better system for 
allocating resources on planet scale than a market. I wish we did. We do 
have better resource sharing capabilities locally though, and I want to 
enable them.

Bob

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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Jul 2007 13:48:25 +0100

Sally,

At 18:29 24/07/2007, Sally Floyd wrote:
>>For the avoidance of doubt, "Bulk per-customer" policing means policing 
>>all traffic crossing the customer's sending access interface using a bulk 
>>token bucket to regulate the bit rate of congestion marked packets to all 
>>destinations together.
>

I think you're right. I can't find it either now. Sorry.

>It is simply in support of "simple best-effort traffic", and in support of

Yes, I know. But saying it's a "separate viewpoint about some related 
topics" reminded me a bit of the polite opener "With the greatest of 
respect...".

Cheers

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Jul 2007 13:53:08 +0100

Sally,

At 18:43 24/07/2007, Sally Floyd wrote:
>>between ISPs and a peering exchange include an element of usage charging 
>>(as well as interface capacity pricing). Whether based on volume, on some 
>>notion of peak demand, or on a hybrid. We propose adding a metric 
>>(congestion volume) that is only slightly less simple than monthly byte-volume.
>>
>>So most of the inter-domain contracts that currently include an element 
>>of usage might switch to using congestion volume. And those that don't 
>>include any form of usage measurements in their contracts might stick 
>>that way. That doesn't make any contracts any more complex.
>
>but about "cost-based pricing based on re-ECN".

Good - that's v precise - thanks.

re-ECN is a proposal to solely add an additional metric to IP. You are 
correct that all the possible economic structures that might be built over 
it are just what I predict might happen. And in that sense, it _can_ 
support a structure of simple pairwise relationships that could also give 
precise incentives for everyone to limit the congestion they cause.

>Our draft is not

Understood.

Cheers

bob