Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

From: [email-masked]
Date: Wed, 16 Oct 2002 12:03:14 EDT

In a message dated 10/11/2002 3:18:54 PM Eastern Standard Time, 
[email-masked] writes:

> On Friday, Oct 11, 2002, at 13:51 America/Montreal, [email-masked] 
> wrote:
> > [MAP] It's become clear to me, with the ongoing discussion under 
> > "Policy and labels", that this requirement REQ-7, as currently 
> > written, could be misinterpreted by some in the future, and may itself 
> > become a hinderance to making progress.
> 
> So far, everyone except you seems to be able to understand the written
> meaning quite clearly.
> 
> For the record, I don't think there is a problem with clarity.
> 
> 

[MAP] The discussion of "Policy and Labels" began with an e-mail from Ken 
that began "there has been a recurring discussion about policy and labels -- 
people
for it, against it, confused by its separation, etc". I have gone back and 
reviewed all the e-mails, and I don't sense the thread resulted in a common 
understanding of the issue or the conclusion, so the confusion Ken referred 
to still exists. Through much of it, there was a problem with knowing just 
what the scope of the discussion was.

If everyone else understands the meaning of "separation of indication and 
policy" in REQ-7, then perhaps someone can explain it in simple, explicit 
terms. What I am most concerned about is that someone will later say that 
this requirement, after we have agreed to it, means that we can not define 
priority levels as something like "low, mediium, and high".

You didn't comment on my suggested rewording. Is it incorrect?

Mike Pierce
Artel

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 16 Oct 2002 11:07:20 -0700

The segregation of mechanism and policy/implementation has long been a 
hallmark of Internet design.  It roots back to router design and is fairly 
well (if tacitly) captured in RFC 1812.

The defining historical example is routers -- the mechanism of forwarding IP 
datagrams is unchanged since the early 80s when IPv4 came into general 
ARPANET use (replacing the older Network Control Protocol which suffered from 
several shortcomings, including this lack of separation).

But routers, like computers, have evolved enormously since then.  The trick 
is to keep the forwarding function unchanged and allow everything else to 
evolve.  Germane to this discussion is the evolution of routing information 
protocols.
	
Initially, the ARPANET routers all ran Routing Information Protocol (RIP) and 
were organized into what we would today call a single autonomous system.  RIP 
limited the diameter of the network (I think to 16 routers??).  If your 
destination was more hops away than that, your grams fell off the edge of the 
earth before arrival (I recall this happening to e-mail from my US box to Oz 
(Australia).  So RIP had to evolve ... but we can't rip (sorry) up the whole 
Internet just to replace the routing information protocol.  Fortunately, the 
foresight of router construction allowed us to update these protocols while 
leaving the basic forwarding mechanism unchanged -- today most of the 
Internet is organized as autonomous systems with BGP as the common exterior 
gateway protocol and most autonomous systems running OSPF as the interior 
(although the specific choice is up to the AS administrator).  

This separation has recurred in the use of the DS (ex TOS) byte in IP 
datagrams.  We've long agreed to allocate that byte in the header -- the 
mechanism.  But until fairly recently, IETF had not defined the semantics 
within that byte -- it had been left up to vendors and implementors.  The 
standardization of DSCP was needed in order to ensure that all ISPs read the 
same meaning out of a particular bit setting (there was a mini-big-endian/ 
little-endian spat in here, as I recall) and provide uniform per-hop 
treatment.  

Extending the reasoning to Ken's comments: we are trying to make the basic 
mechanism setup and future-proof it.  1.  because we need a long-term stable 
mechanism and 2. because we don't know all we need to know about the 
implementing altorithms but we can be very sure that the requirements will 
shift at some time in the fairly near future (a war plan making contact with 
the enemy).  The separation is designed to allow both objectives.

On Wednesday 16 October 2002 09:03 am, [email-masked] wrote:
> that began "there has been a recurring discussion about policy and labels
> -- people

-- 
b
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 17 Oct 2002 14:01:43 +0100

speaking specifically in terms of henning's SIP requirements draft...

> If everyone else understands the meaning of "separation of indication
> and policy" in REQ-7, then perhaps someone can explain it in simple,
> explicit terms. What I am most concerned about is that someone will 
> later say that this requirement, after we have agreed to it, means that
> we can not define priority levels as something like "low, mediium, and
> high". 

simple answer (in my opinion): yes, you can define priority levels as 
"low, mediium, and high", though presumably you'll want to be more 
specific and state "low" in relation to what (e.g., drop precedence).

from the original requirements in Hennings draft...

        REQ-7: Separation of indication and policy: The indication
             should not describe a particular detailed treatment, as it
             is likely that this depends on the nature of the resource
             and local policy.  Instead, it should invoke a particular
             named policy. As an example, instead of specifying that a
             certain SIP request should be granted queueing priority,
             not cause preemption, but be restricted to three-minute
             sessions, the requests invokes a certain named policy that
             may well have those properties.

notice the use of the term "detailed treatment".  I had read that as
*how* with respect to an implementation/mechanism a label is to be 
supported.  next, to borrow from an earlier exchange between yourself 
and Henning...

  Date: Wed, 09 Oct 2002 09:24:55 -0400
   From: [email-masked]
  > If two priority values are "low" and "high", would someone claim that 
  > this violates the above requirement? The "indication" certainly 
  > describes something about the treament.

   From:Henning Schulzrinne
  I think the litmus test is that one should be able to specify, for each 
  such label, at least two independent and interoperable implementations 
  that are different in the behavioral details (such as queueing, 
  dropping, rerouting, traffic controls, etc.).

notice the use of the term "implementations".  again, I read that
as how something is to be done.  If henning changes the wording of
"detailed treatment" to "implementation", does that help you accept
REQ-7 above? (this in addition to the other changes he has agreed on)

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

switching over to my thread of "policy & labels", i originally stated:

  Another way of distinguishing traffic is to use a set of *related* 
  labels. This set may convey various measures of a characteristic that 
  is internal to that set.

I needed to be more general in my statement so that it could be a
applied to SIP or DSCP (or some other type of label).  the intent
of my choosing the word "related labels" and "characteristic" was to 
specifically satisfy your concern/need to be able to define labels
in the general sense of something like "low medium high".  further,
I cited AF as an example of prior art that represents a set of 
labels related to each other (ie, the same class) that have a 
different measure of a shared characteristic (eg, drop precedence).

my hope is that this issue is coming to a close.

> [MAP] The discussion of "Policy and Labels" began with an e-mail from
> Ken that began "there has been a recurring discussion about policy and
> labels -- people for it, against it, confused by its separation, etc". 
> I have gone back and reviewed all the e-mails, and I don't sense the
> thread resulted in a common understanding of the issue or the conclusion,
> so the confusion Ken referred to still exists. Through much of it, there
> was a problem with knowing just what the scope of the discussion was. 

the scope of the discussion is a bit of a rat hole and an unfortunate
distraction.  my need was to say something that can apply to labeling
schemas beyond SIP.  henning's need is to be more specific and focus
on SIP.  (roughly similar to one person talking about fruits, and 
another talking about apples -- a type of fruit).  but its probably best 
to drop this last particular line of discussion.

best wishes,

-ken