Subject: RE: [Diffserv] DSCP marking versus DSCP remarking

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 7 Dec 2000 17:57:03 -0500

I agree with Joel. I was thinking about the scenario where a DS edge router
may also be transiting traffic between two non DS domains and it occured to
me that one may want to mark  as DS on ingress and (re)mark to non-DS on
egress or do nothing at all depending on how the classifiers and markers
were configured and where they were located in the data path.

A remarker is inherently ambiguous because it has been used at times to
describe a mapping from one DSCP to another (map AF1 to EF) and at other
times to enforce an SLS (remark non-conforming AF11 traffic to AF12). It is
clear that a marker just assigns a dscp for the first time. However, would
we consider a mapping from TOS precedence 3 low delay to EF as a remarking
or a marking function? It seems more convenient to me to punt on the
distinction then to draw out and distinguish each unique case.

regards,

-Walter

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, December 07, 2000 4:11 PM
> To: Brian E Carpenter; Kathleen Nichols
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [Diffserv] DSCP marking versus DSCP remarking
> 
> 
> 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:
> >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
> >
> >Kathleen Nichols wrote:
> > >
> > > Robert Moore wrote:
> > > >
> > > ...
> > > >
> > > > 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?
> > > >
> > >
> > > 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
> > >
> > > _______________________________________________
> > > diffserv mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/diffserv
> > > Archive: 
> > 
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml
>
>_______________________________________________
>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: "Robert Moore" <[email-masked]>
Date: Fri, 8 Dec 2000 08:43:05 -0500

Andrew,

My vote is definitely for the one-line version you give below.
The problem with the paragraph version is that a Classifier is
just as ignorant as a Marker about whether a packet is marked
or unmarked.  All the Classifier knows is that a packet does
or does not match a filter like "DSCP = 13" or "DSCP = 0".
Brian's helicopter might know whether a packet that matches
one of these filters is marked.  But the Classifier doesn't
know this.

Regards,
Bob

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

Andrew Smith <[email-masked]>@ietf.org on 12/08/2000 12:03:41
AM

Sent by:  [email-masked]

To:   Brian E Carpenter <[email-masked]>, "Joel M. Halpern"
      <[email-masked]>
cc:   Walter Weiss <[email-masked]>, "[email-masked]'"
      <[email-masked]>, [email-masked]
Subject:  Re: [Diffserv] Re: DSCP marking versus DSCP remarking

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

Brian E Carpenter wrote:

> 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
>
> "Joel M. Halpern" wrote:
>
>> 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
>>> (Diffserv Model draft editor)
>>>
>>>
>>> Robert Moore wrote:
>>>
>>>
>>>> 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.
>>>> 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