Subject: RE: [Diffserv] new droppers,new meters

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 4 Sep 2001 08:10:40 +0200

Vincent,
AFAIK the following documents define metering and marking schemes suitable
for AF:

*	RFC 2697 "Single Rate Three Color Marking Scheme"
*	RFC 2698 "Two Rate Three Color Marking Scheme"
*	RFC 2859 "A Time Sliding Window Three Colour Marker".

Hopefully this note will be useful.
Sorry for using HTML in ths message.
  _____  

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

-----Original Message-----
From: Vincent Wang [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 4:12 AM
To: [email-masked]
Subject: [Diffserv] new droppers,new meters

I have read a lot of things about DiffServ, including all related

RFCs and papers. But I do not find any clue for AF's DiffServ.

In AF's DiffServ, its real meaning is that Diff-macro flows

receive Diff-macro flows treatment; But the Difference Metrics 

between these Different macro flows is never stated.

So DiffServ is just a framework for macro flows treatment. If 

we want to get really meaningful thing ,such as different macro

flows getting better QoS(low latency, high throughput and low

jitter),we must deploy new mechanism ( new droppers,new meters)

 .

Am I right?

---

From: "Krishna Gundamaraju" <[email-masked]>
Date: Wed, 5 Sep 2001 13:50:57 -0400

Hi,

    I have a basic question. The RFC 2697 while explaining the operation in the color aware mode says that the color of the incoming packets may be changed based on its notion of tokens. My question is should we also change the DSCP byte accordingly when changing the color? Or this change in color has only local significance and the DSCP byte should be left unchanged? Please clarify.

    Thanks in advance

Krishna G

  ----- Original Message ----- 
  From: Sasha Vainshtein 
  To: 'Vincent Wang' ; [email-masked] 
  Sent: Tuesday, September 04, 2001 2:10 AM
  Subject: RE: [Diffserv] new droppers,new meters

  Vincent,
  AFAIK the following documents define metering and marking schemes suitable for AF:
    a.. RFC 2697 "Single Rate Three Color Marking Scheme" 
    b.. RFC 2698 "Two Rate Three Color Marking Scheme" 
    c.. RFC 2859 "A Time Sliding Window Three Colour Marker".
  Hopefully this note will be useful.
  Sorry for using HTML in ths message.

------------------------------------------------------------------------------
  With best regards,
                                     Sasha Vainshtein
  email:     [email-masked]
  tel:       +972-3-7659993 (office)
             +972-8-9254948 (res.)
             +972-58-674833 (cell.)

    -----Original Message-----
    From: Vincent Wang [mailto:[email-masked]]
    Sent: Tuesday, September 04, 2001 4:12 AM
    To: [email-masked]
    Subject: [Diffserv] new droppers,new meters

    .

    Am I right?

---

From: "Krishna Gundamaraju" <[email-masked]>
Date: Fri, 7 Sep 2001 15:16:39 -0400

Hi,

    Does DiffServ recommend any 802.1P values for each of the PHBs? Please clarify and point me to the appropriate reference.

    Thanks in advance.

Krishna G
  ----- Original Message ----- 
  From: Sasha Vainshtein 
  To: 'Vincent Wang' ; [email-masked] 
  Sent: Tuesday, September 04, 2001 2:10 AM
  Subject: RE: [Diffserv] new droppers,new meters

  Vincent,

    -----Original Message-----
    From: Vincent Wang [mailto:[email-masked]]
    Sent: Tuesday, September 04, 2001 4:12 AM
    To: [email-masked]
    Subject: [Diffserv] new droppers,new meters

    .

    Am I right?

---

From: Fred Baker <[email-masked]>
Date: Fri, 07 Sep 2001 12:54:08 -0700

At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote:
>     Does DiffServ recommend any 802.1P values for each of the PHBs? 
> Please clarify and point me to the appropriate reference.

we discussed that at one point, but no current proposal is before the 
house. You might suggest one...

_______________________________________________
diffserv mailing list
[email-masked]
https://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, 07 Sep 2001 16:57:15 -0500

Well, I believe that 802.1p was working on this (just as the ATM Forum
was working on diffserv-to-ATM mappings, and MPLS is working on
diffserv-to-MPLS mappings. So this has never been considered as
in the scope of this WG.

You have to be careful anyway. 802.1p supports crude priority, and
diffserv behaviors are not priorities. 

  Brian

---

From: "Andrew Smith" <[email-masked]>
Date: Sun, 9 Sep 2001 20:18:11 -0700

Krishna,

I don't believe IEEE 802.1 ever has looked at standardising how other upper
layers map onto its own mechanisms: the 802 architecture just publishes a
"service interface" to the upper layer to use as it sees fit. So an IETF
group ought to look at the IP->IEEE802 mapping, if indeed it is a problem
worthy of standardisation (the ISSLL WG looked into how to map IntServ
architecture onto IEEE 802 networks in great and gory detail and there is
much published material there that is also applicable to DiffServ - start at
http://www.ietf.org/html.charters/issll-charter.html). I think it best this
way around (but I wish the ATM and MPLS fora luck in their labours).

To be accurate, Brian, IEEE 802.1 supports 8 traffic classes and all
conformant implementations must support *at least* strict priority queueing
between *at least* 2 classes: other mechanisms (e.g. WRR, CBQ) are allowed
and are widely implemented. Last time I heard 802.1 discuss adding
mechanisms to this standard (about 1 1/2 years ago I think - someone will
correct me if I'm wrong - I'm rather a "lapsed" attendee of 802.1), the
general consensus was that the work done by the DiffServ working group
provided sufficient documentation of class-based queueing mechanisms and
their management, that these were very much applicable to 802.1
switches/routers as well as to Diffserv ones (it's just a different
classifier) and that 802.1 didn't need to, and shouldn't, do more. I think
that is still a sensible position for 802.1 to take (and it does make the
DiffServ Model, PIB and MIB drafts all the more important).

It wouldn't be a good idea to have multiple standards groups working on
overlapping things: architecturally speaking QoS policing, queueing and
scheduling mechanisms are (almost) layer-independent. The only pieces that
are really "owned" by one or other layer are classifier elements (DSCP,
6-tuple, IEEE802.1p etc.) - everything else only needs writing down once:
mappings from QoS mechanisms specified at one layer to those specified by
another usually end in tears, or at least not quite the intended effect.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian E Carpenter
Sent: Friday, September 07, 2001 2:57 PM
To: Fred Baker
Cc: Krishna Gundamaraju; [email-masked]
Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping

  Brian

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml