Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean

From: Andrew Smith <[email-masked]>
Date: Fri, 01 Dec 2000 10:54:32 -0800

Brian,

I'm not sure that it is good enough to leave this as an implementation detail: 
it seems to me that this is needs to be declared as either (a) an 
invalid/incomplete configuration or (b) a valid configuration with well-defined 
results. We don't currently have any sort of catch-all "if any part of the DS 
configuration following along a particular datapath is currently invalid, then 
the classifier element that leads to this datapath is considered to be 
not-in-service" rule to handle (a) and I'm not sure how to phrase (b). But I do 
agree with Bob that we need to address the issue more clearly in the draft.

Andrew

Brian E Carpenter wrote:

> Bob,
> 
> I've always interpreted this phrase to mean that the packet
> goes back into the data path it would be on if the router
> knew nothing about diffserv. Whether that is the lowest
> priority queue seems to be an implementation detail.
> 
>   Brian
> 
> Robert Moore wrote:
> 
>> Hi Kwok,
>> 
>> I'll have to say that even with the -06 version of the MIB,
>> I still can't say that I really understand how this works.
>> Take the following example for an egress interface.  The
>> example isn't intended to be realistic -- just to illustrate
>> my point with the smallest number of elements:
>> 
>>            +------+                  +---------+
>>            |  ----|------>Q1(high)-->|Priority |
>> DataPath   |/     |                  |Scheduler|-->zeroDotZero
>>   Start--->|------|------>Q2(low)--->|         |
>>            |\     |                  +---------+
>>            |  ----|--->zeroDotZero
>>            +------+
>> 
>> Clearly packets from the top branch of the classifier,
>> coming from the higher priority queue, will be
>> scheduled out ahead of packets from the middle branch,
>> which has the lower priority queue.  But how will packets
>> from the bottom branch be scheduled out, relative to
>> those from the top two branches?  What does it mean for
>> these packets to receive "no further DiffServ treatment,"
>> relative to packets from the other two branches, which
>> do receive this treatment?
>> 
>> I could make up an answer here:  packets on the bottom
>> branch are treated as if they were on a lowest priority
>> queue serviced by this same Priority Scheduler.  But I'd
>> be more comfortable if there were something in either
>> the MIB or the Informal Model that I could point to,
>> implying that this answer is the correct one.
>> 
>> Regards,
>> Bob
>> 
>> Bob Moore
>> IBM Networking Software
>> +1-919-254-4436
>> [email-masked]
>> 
>> "Kwok-Ho Chan" <[email-masked]>@ietf.org on 11/16/2000 12:02:58
>> PM
>> 
>> Sent by:  [email-masked]
>> 
>> To:   Erez Bashan <[email-masked]>
>> cc:   diffserv <[email-masked]>
>> Subject:  Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it
>>       mean "no further Diffserv treatment is performed" ?
>> 
>> Meaning of "no further DiffServ treatment is performed", as quoted from
>> DSMIB-05 section 3.1.1:
>> "allow normal IP device processing", "Normal IP device processing
>> will depend on the device, for example, this can be forwarding the packet."
>> 
>> Is this sufficient?  May be I should move this explanation to the
>> RowPointer
>> section (5.1), but that section maybe changed in a more dramatic way
>> depending on the outcome of the "Instance Amplification" discussion thread.
>> 
>> -- Kwok --
>> 
>> At 03:24 PM 11/16/00 +0200, Erez Bashan wrote:
>> 
>>> In several places in the MIB (for example if the diffServMeterFailNext has
>> 
>> a
>> 
>>> value of "value of zeroDotZero") a scenario exists in which "no further
>>> Diffserv treatment is performed" on certain traffic.
>>> 
>>> What does it mean ? Is the packet dropped, or should it be handled by
>>> another independent (??) mechanism in the router ? If it is to be dropped,
>>> why isn't it says so explicitly ?
>>> 
>>> Erez

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 15:00:19 -0600

Fair enough, we can clarify it, but am I right that it means
that the packet is simply inserted into the data path as if
diffserv didn't exist (which is presumably equivalent to 
treating it as BE)?

  Brian

---

From: Andrew Smith <[email-masked]>
Date: Mon, 04 Dec 2000 11:03:22 -0800

You see, I don't believe in this thing called "best effort" when you get down to 
the details of the per-hop thing: we insist that all arriving traffic meets a 
complete classifier and is divided into classes. Each class gets a specific 
treatment (e.g. access to forwarding, buffering or scheduling resources) *in 
relation to all the other classes*. There is no "special case", "default" or 
"other" treatment - everything needs to be specified. You should be able to 
model a (2-port) non-diffserv router as a classifier that matches everything, 
followed by a FIFO queue that gets access to all the buffering in the box, 
served by a scheduler that gets 100% of the line bandwidth, whenever there is 
data to send i.e. I believe that there is no such, at this level of the model, 
as "as if diffserv didn't exist".

Andrew

---

From: Dan Grossman <[email-masked]>
Date: Mon, 04 Dec 2000 14:51:49 -0500

> as "as if diffserv didn't exist".
What he said. :-)  Except that treatment can be absolute, as well as in 
relation to all other classes.  And that one can apply the label "best effort" 
to a classifier that matches everything, followed by a FIFO that gets access 
to all the buffering that's left after the other classes, followed by a 
scheduler that gets whatever transmission opportunities are left after all the 
other classes have been satisfied.

---

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

However, "best-effort" is the well-defined default behavior in RFC 2474. IMHO,
saying that when you have nothing else to do to a packet, you treat it as BE
is fully specified.

  Brian