Subject: [Diffserv] RFC 2474 & RFC 2475

From: "Taner OKUMUS" <[email-masked]>
Date: Tue, 15 Aug 2000 18:24:22 -0400

I was going over RFCs 2474&2475 and two statements took my attention.

RFC 2475 section 6.1 says: "Ingress nodes must
   condition all other inbound traffic to ensure that the DS codepoints
   are acceptable; packets found to have unacceptable codepoints must
   either be discarded or must have their DS codepoints modified to
   acceptable values before being forwarded.  For example, an ingress
   node receiving traffic from a domain with which no enhanced service
   agreement exists may reset the DS codepoint to the Default PHB
   codepoint [DSFIELD].  "

RFC 2474 section 3 says: "Packets received with an unrecognized codepoint
SHOULD be forwarded as if they were marked for the Default behavior (see
Sec. 4), and
   their codepoints should not be changed.  "

In case of an unrecognized codepoint which statement is correct? Should we
modify the codepoint or should we leave it as it is and forward as if it is
marked as default PHB?

Any comments?

Ibrahim Taner OKUMUS
Syracuse University
Electrical & Computer Engineering
http://web.syr.edu/~iokumus

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

---

From: Dan Grossman <[email-masked]>
Date: Wed, 16 Aug 2000 10:24:44 -0400

> modify the codepoint or should we leave it as it is and forward as if it is
Looks like an inconsistency which should be fixed.

The case for the RFC 2475 approach appears to favor consistent and predictable 
behavior across DS-domains:  if the DS-domain doesn't know what forwarding 
behavior to apply, then it must either pick one or give up.  

The case for the RFC 2474 approach seems to favor experimentation:  if the 
network doesn't know what forwarding behavior to apply, it must be because 
some other DS-domain does.

There might have been a working group agreement, back around the time of the 
Chicago meeting, that didn't get reflected in one of the two documents.  If 
this is not the case, I prefer the RFC 2475 approach.  

I'll capture the group consensus in the terminology draft, which is overdue 
for revision.

Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Aug 2000 09:32:48 -0500

RFC 2474 is the Proposed Standard and it therefore wins in case 
of inconsistency.

However, the text in 2474 refers to any diffserv node, and contains 
SHOULD. The text in 2475 refers to an ingress node, i.e. it describes 
what a diffserv domain does with incoming traffic. It's entirely consistent
to apply the RFC 2475 recommendation at an ingress node, thereby
overriding the SHOULD.

Thanks for pointing this out. We may need to clarify the wording slightly
in some future revision.

Since this all amounts to traffic conditioning, it indeed will be under
policy control as Jay Wang pout out.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 16 Aug 2000 15:55:01 +0100 (BST)

> to apply the RFC 2475 recommendation at an ingress node, thereby

imo informational RFCs shouldn't be overriding standard RFCs; if they
do correctly, you need to revise the standards document. SHOULD
carries a lot of weight.

> Thanks for pointing this out. We may need to clarify the wording slightly

yes. definitely.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dan Grossman <[email-masked]>
Date: Wed, 16 Aug 2000 11:11:47 -0400

> to apply the RFC 2475 recommendation at an ingress node, thereby
If this is the view of the working group, let us be explicit about it.  The 
RFC 2474 wording should apply to DS-interior nodes, and the RFC 2475 wording 
should apply to DS-ingress nodes.  I can create some words to this effect.

> Thanks for pointing this out. We may need to clarify the wording slightly
The terminology draft is a good home for clarifications like this.  
Implementors should not have to resort to lawyer logic to know how to do the 
right thing.

---

From: John Schnizlein <[email-masked]>
Date: Wed, 16 Aug 2000 12:06:10 -0400

IMHO the implication of SHOULD in a standard is clear:
do it this way unless you have a good reason otherwise.
There is no problem with an information about what good reasons
(ingress node in an architectural view) might exist.
This is not lawyer-language interpretation; it is the normal
description of general cases with special exceptions that 
are the daily work of programmers.

This is not to say that the situation couldn't be made more clear
when the standards process calls for a revision of RFC 2474.

John

At 03:55 PM 08/16/2000 +0100, Lloyd Wood wrote:
>> what a diffserv domain does with incoming traffic. It's entirely 
>> consistent to apply the RFC 2475 recommendation at an ingress node, 
>> thereby overriding the SHOULD.
>

At 11:11 AM 08/16/2000 -0400, Dan Grossman wrote:
>
>Implementors should not have to resort to lawyer logic to know 
>how to do the right thing.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Aug 2000 10:51:16 -0500

I think what is missing in 2474 is the observation that ingress 
conditioning is the most common case where the SHOULD may be
overridden. 

In response to Lloyd's comment, we would probably be reluctant to
attempt to standardize ingress conditioning, since that may depend
very much on ISP practice. That's why it's in an informational
document. 

  Brian

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 16 Aug 2000 10:18:33 -0700

What Brian said. With a reminder that there was a GREAT deal of
discussion on this and this was the WG consensus. That was
before Chicago.

	Kathie

---

From: Dan Grossman <[email-masked]>
Date: Wed, 16 Aug 2000 14:15:36 -0400

> discussion on this and this was the WG consensus. That was
Would you summarize exactly what the WG consensus was?

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 16 Aug 2000 12:12:29 -0700

> Would you summarize exactly what the WG consensus was?

Following up on what Brian has said, the intent was for "interior"
routers or, more generally, where a packet shows up to be steered
into a particular queue. The overwhelming consensus was that if
a packet showed up with a DSCP that hadn't been explicitly mapped
to any particular queue (in the sense of PHB), it should get
treated the same way as a packet marked for Default. The alternatives
are to put it in some other queue, which could mess up some
provisioning for the network or to drop it. Those are the only
alternatives within the framework of 2474. For a network with
an "excess" queue or PHB (something that gets serviced after DE),
perhaps that might be a better alternative, hence "SHOULD". Or,
part of a network might have nodes that can only "steer" on the
3 bits formerly known as "IP precedence", hence technically speaking
a six-bit pattern might be unknown to that node, but might be mapped
based on its lower 3 bits only if the network operator had set things
up with that expectation.

Anyway, the WG seemed to think that dropping a packet with a DSCP
that was unknown to a particular node was not a good thing, but
putting it into another (possibly provisioned) queue was also not a good
thing. This seemed operationally sensible.

---

From: Dan Grossman <[email-masked]>
Date: Wed, 16 Aug 2000 15:17:07 -0400

Sounds reasonable.  I'll write that up as soon as I'm finished with one or two 
other little projects I've been working on.  Which may be after a much needed 
vacation.

Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Aug 2000 15:29:18 -0500

Dan, the piece of 2474 that Taner cited *was* the conclusion of that discussion.
So the only change is the note that ingress traffic conditioning would
override the SHOULD, I believe.

Have a good vacation, in any case.

   Brian