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

[Bob Briscoe <[e-mail]>]

Sally,

At 18:01 24/07/2007, Sally Floyd wrote:
>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.

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.


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

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


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

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


Bob

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

____________________________________________________________________________
Bob Briscoe, <[e-mail]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]