[Tsvwg] Re: terminology issues in draft-floyd-tsvwg-besteffort - "simple best effort"

[Sally Floyd <[e-mail]>]

Bob -

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

> 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.

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