Subject: [Ieprep] policy & labels

From: Ken Carlberg <[email-masked]>
Date: Wed, 09 Oct 2002 17:06:26 +0100

there has been a recurring discussion about policy and labels -- people
for it, against it, confused by its separation, etc.  so it may be helpful
to have a separate discussion about the subject so that we can put it to 
rest andmove on to other stuff.

so, to start the fun, lets see how the following statement grabs folks...

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

  The process of distinguishing traffic by means of a label can be
  accomplished in one of two ways.  The first is with a single label, 
  which acts as a binary on/off indicator distinguishing a set of
  data/flows from all other data/flows.  The characteristics (e.g., drop 
  precedence) that one may apply to this single labeled traffic versus 
  all other traffic is what is refered to as policy.  In addition, the 
  type of traffic (VoIP, ftp, http, etc.) associated with a label is a
  separate issue and defined via a policy.  
 
  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.  An example of this case is the Assured 
  Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in
  RFC2597.  Within each AF class, M different levels of drop level 
  precedence may be assigned to an IP packet.  Note that the exact level 
  of drop precendence is not defined for any level.  Further, different 
  classes, and different PHBs, are unrelated.
 
  From this example, we can make a more general statement and say that 
  one may choose to attribute a type of characteristic to a related set 
  of labels.  However, the characteristics between one set of defined 
  labels to all other sets of unrelated labels is separate and not part 
  of the defined label set.  

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

Does the above seem reasonable statement to make?  Does it need to be
more precise, more constrained, less constrained? 

let thine arrows fly forth :-)

-ken

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Oct 2002 17:13:40 -0400

My 2c (Euro):

I think there are actually two separate problems here, binding and 
specificity.

As usual in networking, this is partially a question of indirection or 
bindings, I think. Any protocol identifier value can either mean a 
specific thing or be bound to a specific interpretation at "run time" or 
per "session". This binding can be more-or-less-static, as part of some 
profile (generally bad), or dynamically signaled, as, say, the binding 
between RTP payload type numbers and codecs is in SDP. (SIP is, at 
heart, a binding protocol.) Late binding is necessary if, for efficiency 
reasons, the space of the identifier is insufficient to contain all 
possible values and if only a small set is likely to be needed at the 
same time.

This is, generally, not the case for text-based protocols, as there is 
no shortage of label space. (It's equivalent to a variable-length 
integer of unbounded length.) Thus, dynamic binding of some short 
identifier to the "real" thing is not necessary here and likely to be 
counterproductive.

If my understanding of DiffServ is correct, there is a recommended DSCP 
for each PHB, but one could bind one locally, with a yet-to-be-specified 
mechanism. One reason is that the DSCP is very short (6 bits), so 
running out of code points is a very real problem.

A separate question is the level of detail that is specified; this is 
sometimes referred to as "policy vs. mechanism". A crude way to put this 
might be "externally visible behavior vs. local implementation". For 
example, it may be sufficient to specify that "for the same call, if you 
only change the labeling, it should not get worse treatment". This 
avoids having to specify behavior which may be left to local 
capabilities, such as displacement of existing calls.

In general, I think you want the minimum amount of mechanism detail so 
as to give maximum freedom to implementations to optimize for local 
circumstances ("narrow interface"). As one example, the PHBs don't 
specify precisely how the queueing mechanism needs to be implemented or, 
as another example, IntServ guaranteed service doesn't specify the 
precise algorithm, just the externally visible behavior, even though 
there's only one known mechanism to implement it precisely.

In our case, however, we are mostly "importing" external descriptions. 
The specificity of the behavior description is given by others. SIP is 
just the messenger. This argues, in particular, that we can't just have 
a limited set of mechanisms ("don't queue", "preempt"), as that would 
make extensions difficult.  (On the other hand, if you know you can 
exhaustively specify the list of behaviors, it's clearly better to do 
that, as it reduces the number of failure cases. You can then test for 
all bit combinations and know that nobody can surprise you.)

It does not, in my opinion, rule out a reference to a very detailed 
scheme. Similarly, in principle, you could have fairly detailed PHB 
descriptions that govern all relevant packet treatment. Indeed, recent 
history is an indication that too abstract a specification may not be 
implementable at all, leading to a more precise (and thus constraining) 
specification. Clearly, this is not a bright line, to the left of which 
lies sainthood and to the right religious dogma. (One could draw 
parallels that religious denominations come to different conclusions as 
to how much their relevant texts are policy vs. mechanism, but I won't 
go there.)

I don't think anybody in the group is arguing that we should have an 
exhaustive set of behavior descriptions, where the labeling is some 
combination of these parameters. This does not mean that, as argued 
above, that you need to apply additional layers of indirection.

At the danger of more analogies, the problem is not dissimilar to 
including URIs with multiple schemes (which SIP does a lot...). Relevant 
end systems need to know what to do with them, but the protocol itself 
can be fairly open to new ones, without affecting the core protocol 
functionality itself.

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 11 Oct 2002 13:32:50 +0100

thanks for the additional perspective.  my default thinking process
tends to center on the relationship of labels and a desire to retain 
a great deal of flexability in their specification and association of
characteristics.

I want to have a schema that allows one the freedom to describe the
relationship (importance?) of *related* labels as in the case of MLPP.
And I also want to have a separation of unrelated labels and a separation
of the type of mechanism to achieve the characterization associated
with a label -- this separation in the form of local policy for whomever 
is providing support N sets of labels.  In the case of SIP, presumably
in the form of N namespaces.  And before anyone panics, the N set is not
all defined namespaces, but just those that have been contracted by a 
provider to support.

-ken

ps, I believe we are in agreement

-----------------Original Message-------------------

Subject: Re: [Ieprep] policy & labels
From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Oct 2002 17:13:40 -0400 (22:13 BST)
To: Ken Carlberg <[email-masked]>
Cc: [email-masked], [email-masked]

My 2c (Euro):

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 11 Oct 2002 08:45:53 -0400

I'm concerned that some folks are reading "label" and inferring
"SIP or other telephony application label".  I read "label" and
understand that this might be a telephony application label
or a DiffServ code point or some other non-telephony label
or some other non-application-layer label.

This difference in reading seems to be causing (some) folks to talk past
each other in a way that does not help the group to converge to 
consensus.

For my part, I think that where "label" happens to be an instance of
a DiffServ/IP ToS bit pattern, people are confused if they think that
more than 2 or 3 total user labels will be available in real deployments
from large ISPs (and having DiffServ supported at all for customer 
traffic
is not a given, by the way).[1]

Ran
[email-masked]

[1] The long-standing "Internet Control" code point from RFC-791 is 
widely
used in ISP routers to prefer BGP traffic over other traffic in order 
to maximise
Internet reachability and to maximise stability of inter-domain routing.

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 11 Oct 2002 13:56:12 +0100

> or some other non-application-layer label.

yes, totally agreed.  part of the motivation of the original note 
was to get possible feedback that would allow us to expand on the 
requirement (of the general-requirements draft) on the separation of 
policy and labels.

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Oct 2002 09:11:55 -0400

As an add-on: while general discussions are certainly useful and maybe 
educational, we, as a WG, also, I believe, want to get some documents 
out the door. Thus, may I suggest that people clearly state
- which, if any, WG document they are addressing in their comments;
- whether they are suggesting changes to an existing document (and 
clearly state those changes, if not as a wording suggestion, then at 
least in what is unclear, incomplete or wrong);
- or requesting clarification without expecting changes.

This would certainly help one document author...