Subject: [Diffserv] DSCP marking versus DSCP remarking

From: "Robert Moore" <[email-masked]>
Date: Tue, 5 Dec 2000 12:25:30 -0500

In the DiffServ Informal Model, MIB, and PIB, there
is a distinction drawn between a marker that marks
unmarked packets, and one that remarks packets that
had been marked previously.  This distinction appears
most clearly in section 6.1 of the Informal Model.
The MIB and the PIB make it implicitly, by importing
the terms "mark" and "remark" from the Informal Model.
This distinction presupposes that among the packets
coming into a marker, some can be identified as
already marked, and others can be identified as
unmarked.  I don't believe that this is the case.

In QDDIM, we have come down squarely on the side that
says there is no such thing as an unmarked packet, and
thus no distinction between packet marking and packet
remarking.  Every packet has one of 64 values, decimal
0 - 63, in the DSCP field.  Each of these values,
including 0, is a legitimate DSCP.  So a DSCP marker
always takes in a packet that is already marked with a
DSCP, and marks (or remarks - which word we choose isn't
important) the packet with another DSCP, which may or
may not be the same DSCP as the one the packet had
when it came into the marker.  Based on this view, we
removed from the MarkerService class in QDDIM a boolean
property CanRemark, which said whether a marker was
allowed to mark all packets, or only packets that were
not already marked when they got to it.

This is *almost* just a question of wordsmithing in the
three diffserv WG documents.  But not quite.  If there is
actual disagreement in the WG about whether there is such
a thing as an unmarked packet, that is, a packet that's
not marked with any DSCP, then the question should be
discussed until the WG reaches a consensus one way or the
other.  Does everybody agree with the QDDIM team that
there is no such thing as a packet unmarked with any DSCP?

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 05 Dec 2000 12:24:00 -0800

Robert Moore wrote:
...
> there is no such thing as a packet unmarked with any DSCP?

With my WG co-chair hat OFF, I agree that we should just have
a "marker" as a primitive element. I would not phrase this as
saying "there is no such thing as a packet unmarked with any
DSCP". If someone chooses to use that phrase to describe
packets marked with an unknown, illegal, or unverified DSCP,
it should not have any architectural effect. 

	Kathie

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 10:23:28 -0600

I believe this is quite clearly discussed in RFC 2474/5.
Packets arriving from a non-DS domain can't be regarded
as containing a meaningful DSCP value until they have
been classified and marked.

I don't think that Policy WG documents should be in the
business of tweaking the diffserv architecture.

  Brian

---

From: Andrew Smith <[email-masked]>
Date: Thu, 07 Dec 2000 11:52:55 -0800

I'm slightly confused as to whether I need to change anything in the Model draft 
here: I think, to paraphrase Brian's answer, that there *is* such a thing, 
conceptually, as an unmarked packet. You can tell, by implicit context, whether 
a packet is or is not already "marked" (it's a "policy" or "trust" thing, in the 
abstract sense of those terms).

Do I have this right?

Andrew Smith
(Diffserv Model draft editor)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 07 Dec 2000 16:11:05 -0500

Actually, I believe that this misses the point of the issue Bob is 
raising.  From the point of view of the processing elements, I can find no 
difference between a marker and a remarker.  If one places the processing 
element on a data path such that the packet is coming from outside 
diffserv, then it is a marker.  If it could have been previously remarked.

The problem is that the informal model actually says that one might have a 
processing element that was allowed to be a marker, but not a 
remarker.  That would require the processing element to know the history of 
the packet.  It would need to know whether the packet arrived over an 
interface considered to be inside or outside the diffserv domain.  For 
those arriving over an outside interface that was not considered to be 
applying useful diffserv markings, it would have to know if the current 
value in the DSCP came from the input or was put there by an earlier marker 
in the processing stream.

These are things that the "marker" element has no way to determine.  The 
human being placing it there may have a way to tell.  But then, the human 
being can put in a classifier if he is concerned about what value is in the 
field.  It is NOT up to a marker to look at the packet and decide if it 
should stamp the value.  If the packet gets to the marker, mark it.

Yours,
Joel M. Halpern

At 10:23 AM 12/7/00 -0600, Brian E Carpenter wrote:
> > Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
>
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 07 Dec 2000 17:24:33 -0500

As I said in another recent reply, I really believe that this is not the case.
Even a human being looking from outside the box might well have trouble 
telling if a packet sitting at a marker is already marked or not.  Suppose 
that one of the several paths to this marker goes through an earlier 
marker/meter sequence.  Suppose that the customer SLA says that the 
customers diffserv marking will be respected.
The device component is certainly in no position to tell the difference.
It seems to me that this distinction is distracting and error prone.  It 
can not translate to a difference in resulting behavior.

Yours,
Joel M. Halpern

At 11:52 AM 12/7/00 -0800, Andrew Smith wrote:

>I'm slightly confused as to whether I need to change anything in the Model 
>draft here: I think, to paraphrase Brian's answer, that there *is* such a 
>thing, conceptually, as an unmarked packet. You can tell, by implicit 
>context, whether a packet is or is not already "marked" (it's a "policy" 
>or "trust" thing, in the abstract sense of those terms).
>
>Do I have this right?
>
>Andrew Smith

---

From: Enrique Hernandez-Valencia <[email-masked]>
Date: Thu, 07 Dec 2000 18:45:24 -0500

Indeed, and an edge box all packets are "marked" by virtue that the
DSCP field MUST contain some codepoint, no matter how the source chose 
that codepoint.

Even if the customer that generates such flow has an SLA with a 
network, it is still the responsibility of the network to make sure 
that in fact  the codepoint(s) in that flow are consistent with 
that SLA.

> can not translate to a difference in resulting behavior.

If the customer has an SLA that indicates "the customer diffserv marking
will be preserved", it seems that the only way for an ISP to provide
such 
a service over its "diffserv domain" is to "tunnel" the customer flow 
-using its preferred tunneling mechanism-, since there is no way an 
edge box can  guarantee/trust that a customer indeed will mark its flow 
consistently with the usage within a given ISP "diffserv domain".

Enrique

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 17:44:49 -0600

I certainly agree that the marker itself can have no idea, and need have
no idea, whether it is the first marker to mark a given packet - i.e.
there is no functional difference between marking and remarking. It's 
only if you could watch the packets from a helicopter, and observe
them passing from a non-DS domain into a DS domain, that you would know
the difference. It's certainly a good idea to reflect this in the
documents.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Andrew Smith <[email-masked]>
Date: Thu, 07 Dec 2000 21:03:41 -0800

That's also exactly what I meant in my response. The "you" in my statement was 
meant to be Brian's helicopter, not a Marker element in the Model.

But I'm still unclear if the Model draft needs to change. The only re-marking 
described is in 6.1 in the context of the things that a DSCP Marker element 
might do:
   "DSCP Markers are 1:1 elements which set a codepoint (e.g. the DSCP
   in an IP header). DSCP Markers may also act on unmarked packets (e.g.
   those submitted with DSCP of zero) or may re-mark previously marked
   packets."

Would it be clearer instead to say something like:
  "DSCP Markers are 1:1 elements which set the DSCP in an IP header. DSCP 
Markers might, for example, act on packets that a previous Classifier element 
has deemed to be unmarked (e.g. because they were received from a non-Diffserv 
domain). They might also re-mark previously marked packets (e.g. those that a 
previous Classifier element has recognised as having valid DSCP values but which 
now need to be marked with a different one, perhaps because they failed to 
conform to a Meter)."

Or should the Model, at this point, just not go there and say merely:
  "DSCP Markers are 1:1 elements which set the DSCP in an IP header."

Joel wrote:
 > The problem is that the informal model actually says that one
 > might have a processing element that was allowed to be a marker,
 > but not a remarker
I'm not quite sure which part of the Informal Model draft Joel is referring to 
(is it the "or" that you don't like? It was not meant to be an "exclusive or", 
just an "and/or") but perhaps my proposed re-wording above (using "also") helps 
clarify?

But that still sits uneasily with Walter's statement that "It is clear that a 
marker just assigns a dscp for the first time" (perhaps I'm reading that 
statement in the wrong context?).

Any more thoughts on this? I think we're in a rat-hole - should we perhaps work 
offline to clarify what it is that we're all mis-understanding?

Andrew

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 08 Dec 2000 09:57:23 -0500

On the question fo whether to refer to markers and re-markers in teh 
description of the marker action element, I would prefer that we went with:

>  "DSCP Markers are 1:1 elements which set the DSCP in an IP header."

If we want to mention the omniscient view-point distinction petween marking 
and remarking it would go in some text that talks about the fact that the 
entire processing stream may be different for packets considered to have 
been processed (marked) from those which have not been sanitized as it were.

Yours,
Joel M. Halpern

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 08 Dec 2000 09:56:36 -0800

I concur with the Joel's support for the short form text Andrew
proposed below.

Arguably the DSCP is always set by someone, it is merely a
question of whether you (the router) agree with the value to which
it was set. 'Marking' reflects a belief that the current DSCP was
initialized by a NON-diffserv-aware/compliant process (e.g. accidentally
in someone's OS, etc...).  'Remarking' reflects the belief that the
DSCP was previously set by a diffserv-aware process, but you now possibly
disagree with the choice of DSCP (e.g. your metering stage indicates packet
should have a different drop precedence, etc) Yet in either case, the
functional element is simply assigning a DSCP to a packet (with no
inherent sense of a packet's temporal or topological history).

cheers,
gja

-- 
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley