Subject: RE: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it me an

From: "Lemaire, Tom" <[email-masked]>
Date: Mon, 4 Dec 2000 17:40:55 -0500

It is desirable to have everything specified, but an ISP transitioning
from a one class world to a multi-class world will appreciate well-defined
handling of the cases where (1) packets are not explicitly classified into
a traffic class on the ingress side of the box, and (2) bandwidth/buffers
for a given class are not explicitly allocated on the egress side of the
box.

You can specify that such conditions must not exist, but when they
inevitably arise due to customers incrementally configuring/deploying
diffserv, it would be helpful if the specs make the behavior well-defined.

One way to do this is by designating one traffic class as the 'default'
class.
There are other ways, but leaving the behavior undefined just means that
implementations will vary.

Tom Lemaire
Unisphere Networks

-----Original Message-----
From: Andrew Smith [mailto:[email-masked]]
Sent: Monday, December 04, 2000 2:03 PM
To: Brian E Carpenter
Cc: diffserv
Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it
mean

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

Brian E Carpenter wrote:

> 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
> 
> Andrew Smith wrote:
> 
>> 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.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.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