Subject: [Diffserv] WG Last Call: draft-ietf-diffserv-phbid-00.txt

From: Kathleen Nichols <[email-masked]>
Date: Mon, 29 Nov 1999 15:45:00 -0800

This is to note that we are in Working Group Last
Call on draft-ietf-diffserv-phbid-00.txt:
http://search.ietf.org/internet-drafts/draft-ietf-diffserv-phbid-00.txt

It was agreed in the WG meeting in DC that the document should procede.

Comments should be sent to the list as a follow up to this message.
The last call will end on December 14. 

        Kathie and Brian

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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 30 Nov 1999 10:59:12 +0200 (EET)

since some phb groups may have many code points, not all of which
are necassarily in use by a particular service, a mask would be a more
flexible solution than the single 14th bit.

-- juha

---

From: John Schnizlein <[email-masked]>
Date: Tue, 30 Nov 1999 09:27:09 -0500

I don't see how this could work. A field over which the mask might 
be applied is prohibited by the definition of the DSCP [RFC 2474]:

   DS-compliant nodes MUST select PHBs by matching against the entire 6-bit
   DSCP field, e.g., by treating the value of the field as a table index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.

While the recommended DSCPs for AF encode the different drop precedences
in bits 3 and 4, all values are in use even if not distinguished [RFC 2597]:

   Within each AF class, a DS node MUST accept all three drop precedence
   codepoints and they MUST yield at least two different levels of loss
   probability.

Although the distinction beween just two levels of drop precedence
is encoded in bit 3 in the recommended DSCPs, this encoding cannot
be relied upon for other PHB groups because of the prohibition above.
It also seems unlikely that recommended DSCPs for new standard PHB
groups would be able to find bit-fields to enable the masking proposal
because of the coverage of CSC, EF and AF.

   If a DS node only implements two different levels of loss probability
   for an AF class x, the codepoint AFx1 MUST yield the lower loss
   probability and the codepoints AFx2 and AFx3 MUST yield the higher
   loss probability.
   ...
                        Class 1    Class 2    Class 3    Class 4
                      +----------+----------+----------+----------+
     Low Drop Prec    |  001010  |  010010  |  011010  |  100010  |
     Medium Drop Prec |  001100  |  010100  |  011100  |  100100  |
     High Drop Prec   |  001110  |  010110  |  011110  |  100110  |
                      +----------+----------+----------+----------+

John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 1999 15:30:30 -0600

I agree with John (speaking as co-author of the draft). The PHBID is not intended
to convey semantics.

   Brian