Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3

From: Andrew Smith <[email-masked]>
Date: Thu, 1 Jun 2000 12:03:15 -0700

Still looking for some concrete proposals.

Andrew

> -----Original Message-----
> From: Brijesh Kumar [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 8:31 AM
> To: 'Brian E Carpenter'
> Cc: [email-masked]
> Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model
> Draft 3
...
> My main comments
> were with regards to including some explanation regarding 
> ingress queueing
> and egress classification and metering, and modeling the 
> classifier and the
> meter both with 1 to N, and M to N mappings.

_______________________________________________
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: Thu, 01 Jun 2000 15:09:14 -0500

Right. This note is not directed at Brijesh in particular, but to everybody
who has comments:

* Specific proposed changes to the text are useful to the WG.

* Generic or vague comments are not useful at this stage, which is the
  final tuning of a well-established draft.

   Brian
   diffserv co-chair

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 2 Jun 2000 13:33:56 -0400

> Still looking for some concrete proposals.

Hi Andrew,

Here are somewhat re-worded text in line with our previous discussion. I
have tried to keep the text as close to the
previous text as possible. Feel free to critically examine
changes, and the motivation for the change.

Section 3.2:

Suggested change for Paragraph : “Note that …….selection”. In section 3.2

[ My motivation for the suggested change:  To add clarity by emphasizing
what will likely to be the most common implementation, what is likely to be
the less common. Even though model isn't an implementation architecture, the
model still must be close to actual implementations.]

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.

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.

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.

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.

Cheers,

--brijesh
Ennovate Networks Inc.,