Subject: Re: TOS byte definition is not "unclear"

From: Phil Karn <[email-masked]>
Date: Tue, 19 Dec 2000 12:28:36 -0800

Thanks. I'll make the appropriate changes.

Phil

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 19 Dec 2000 12:19:16 -0800

As I said in the IETF meeting last week, the current status of
the TOS byte is not at all unclear. RFC 2780 quotes RFC 2474 and notes:

"4.2 IPv4 Type of Service field

   The Type of Service field described in [V4] has been superseded[DIFF]
   by the 6-bit Differentiated Services (DS) field and a 2-bit field
   which is currently reserved.  The IANA allocates values in the DS
   field following the IANA Considerations section in [DIFF].  [ECN]
   describes an experimental use of the 2-bit "currently unused" field.
   Other experimental uses of this field may be assigned after IESG
   Approval processes.  Permanent values in this field are allocated
   following a Standards Action process."

My understanding is that the 2-bit CU field is possibly being assigned
to ECN. I would suggest checking with the transport ADs.

There certainly ARE open questions in building services in a diffserv
architecture, though there are also some clear uses of diffserv
currently. In addition, the flexibility of the "EXP/LU" codepoints
in the DS field allow for a range of uses.

	Kathie

---

From: Dan Grossman <[email-masked]>
Date: Tue, 19 Dec 2000 16:15:04 -0500

> to ECN. I would suggest checking with the transport ADs.
There was concensus in the transport area meeting to progress ECN  to 
"Proposed".
> in the DS field allow for a range of uses.
Which is of marginal relevance to PILC.  

I think that I was given an assignment to re-do this section (again).  The 
points to be made were:
- that QoS for IP is not mature;  ref. RFC 2990.
- we have two architectures, Intserv (ref RFC  1633) and Diffserv (ref RFC 
2475). A few words about each, and also mention that RFC2990 envisions intserv 
over diffserv as a possible unified approach
- however we get there, L2 forwarding needs to be able to be "clued" by the L3 
service (in case of Intserv) or PHB (in case of Diffserv).

Now, if the group wants, the text I will draft could talk more about 
mechanisms, including the DS field.  But if I do that, it will also have to 
get into MF classifiers, BA classifiers, RSVP, flowspecs, policy, traffic 
conditioning, scheduling, discarding and queueing.  It would very specifically 
have to say that the DSField is usable by PILC ONLY when the link is inside a 
DS-domain (either in an interior node or inside the classifier block of a 
DS-ingress node) and ONLY to the extent that the link behavior contributes to 
the defined per-hop behavior associated with the DSCP.  With emphasis that a 
PHB is **NOT!*** an end-to-end service.  And that outside a DS-domain, an 
equivalent of MF classification serves to map flows to L2 forwarding behavior. 

But in any event, the existing text is not only wrong, but also a non-sequitir.
> 	Kathie
Dan