Subject: [Diffserv] RE: Suggested changes to Diff-Serve Conceptual Model Draft 3

From: Andrew Smith <[email-masked]>
Date: Fri, 2 Jun 2000 11:26:40 -0700

Brijesh,

Thank you for your work on the proposed changes: but I disagree with all of
them for the reasons stated below.

> -----Original Message-----
> From: Brijesh Kumar [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 10:34 AM
> To: 'Andrew Smith'
> Cc: [email-masked]
> Subject: Suggested changes to Diff-Serve Conceptual Model Draft 3
... 
> By modeling the similar elements on both ingress and egress 
> components, it
> is not implied that all elements be implemented on each 
> interface. Each
> implementation will choose the suitable interface for implementing a
> diff-serv element.  Traffic classification, metering and TC 
> actions (e.g.,
> marking, dropping of non-conformant traffic and counting) are 
> typically
> considered ingress interface functions, but   some 
> implementation may choose
> them to implement on the egress interface instead. Similarly, 
> output traffic
> shaping and PHB queueing are typically considered egress interface
> functions, but some implementation may choose them to 
> implement on ingress
> interface instead.  Some implementations may also choose  to 
> implement one
> or more diff-serv elements  on both interfaces, thus placing 
> multiple sets
> of these elements in series and/or parallel. This model 
> accommodates all
> such design decisions.

[Andrew] I don't think I agree with what you think is typical. That's
precisely why I left it as neutral as possible in the -03 draft, whilst
still saying something useful.

> Section 4.1:
> 
> Suggested change for Classifiers
> 
> [My motivation for the change: A separate multiplexer element is not
> required since the multiplexing occurs automatically as a 
> result of merge of
> multiple traffic flows in the data path in a centralized 
> router. I think it
> will be nice to maintain one to one mapping between the 
> diff-serv model
> objects, and the way implementers will most likely realize diff-serve
> elements using c++ classes. This will make section 6.5 on multiplexer
> redundant.)
> 
> Classification is performed by a classifier element.  A 
> classifier can be
> modeled either as a 1 to N mapping device or as a M to N 
> mapping device. In
> the former case, a classifier takes a single traffic stream 
> coming from an
> interface as input and generates N logically separate traffic 
> streams as
> output. In the later case, multiple traffic streams from 
> several interfaces
> are  presented at the input of the classifier  which 
> generates N logically
> separate traffic streams as output.  Multiplexing at the input of the
> classifier is a result of common ingress queueing of multiple traffic
> streams from several interfaces.

[Andrew] The Model draft defines a "Multiplexer element" (see 6.3) for
exactly this reason. There is no need to have 2 alternate representations
for the Classifier element.

> Classifiers are parametrized  ......paragraph ............ (same as in 
> the old draft).......
> 
> 
> When multiple ingress sub-interfaces feed through a single 
> classifier the
> interface number can be considered by the classifier as a 
> packet attribute
> and be included in the packet's classification key. This 
> optimization may be
> important for scalability in the management plane. Another 
> example of a
> packet attribute could be an integer representing the BGP 
> community string
> associated with the packet's best-matching route.

[Andrew] No, for same reason.

> Section: 5
> 
> [ The same arguments as for the previous  section: ]
> 
> A meter  can be modeled either as a 1 to N mapping device or 
> as a M to N
> mapping device. In the former case, a meter takes a single 
> traffic stream
> coming from an interface as input and generates N logically 
> separate traffic
> streams as output. In the later case, multiple traffic 
> streams from several
> interfaces are  presented at the input of the meter  which generates N
> logically separate traffic streams as output.  Multiplexing 
> at the input of
> the meter is a result of common ingress queueing of multiple 
> traffic streams
> from several interfaces.

[Andrew] Ditto.

Andrew

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Jun 2000 14:36:32 -0500

Since Andrew attempted to respect the consensus as it was understood
in Adelaide, I'm going to state that these changes don't go in unless
a lot of other people tell us that they agree with Brijesh.

   Brian Carpenter
   diffserv co-chair

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 2 Jun 2000 16:37:27 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Brian E Carpenter
> Sent: Friday, June 02, 2000 3:37 PM
> To: Andrew Smith
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [Diffserv] RE: Suggested changes to Diff-Serve Conceptual
> Model Draft 3
>
>

Brian,

I suggest if there is already a consensus, then don't even open it. It's not
a problem with me, and more so while writing I realized that it hardly
affects any thing in MIB and PIB drafts (or in any implementation). Let us
close this discussion as it is (it's OK if multiplexer is realized
separately as in the draft, instead of the way I tried to combine with the
classifier and the meter.).

--brijesh
Ennovate Networks Inc.,