Subject: RFC 793 issue

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 1999 08:16:40 -0500

Diffservers,

It has recently been observed that the diffserv model has 
potential impact on TCP implementations that strictly implement
the provisions of RFC 793 regarding the old IP precedence
bits (bits 0, 1 and 2 of the type-of-service byte in IPv4,
renamed the Differentiated Services field for the purposes
of the diffserv model). There is an explanation, and a
proposed change to the TCP specification, in
draft-xiao-tcp-prec-00.txt. 

In particular, the diffserv architecture allows intermediate
routers to rewrite the bits in the DS field according to
locally installed traffic conditioning specifications. Concern
has been expressed that such rewriting may trigger TCP resets
in strict implementations of RFC 793. Regardless of whether
the TCP specification is updated, this concern must be addressed
for existing implementations.

RFC 793 assumes that the old IP Precedence bits are transmitted
unchanged and symmetrically across the network. In practice, 
TOS bytes are commonly rewritten (zeroed) today, to
prevent abusive use of high precedence, except in networks
specifically configured to allow the use of precedence for user
traffic. Diffserv does not change this situation, except that
ad hoc router configuration is replaced by diffserv traffic
conditioning specifications. If a network requires certain
precedence values to be transmitted unchanged, these can be
configured as DCSPs mapped to a PHB that never re-marks traffic.
In practical terms, this changes nothing compared to today
(and meets the Diffserv goal of backwards compatibility
with IP Precedence).

A secondary point is that even when the DSCP is rewritten by 
intermediate routers, in most cases all packets of the same flow will 
have their DSCP rewritten in the same way. To date, only one per-hop
behavior (PHB) has been standardized that allows different packets 
from the same flow to receive different code points. This is the
Assured Forwarding PHB defined in RFC 2597. However, even when
different AF packets from the same flow carry different DS code
points, they all have (by design) the same value in bits 0-2, i.e.
in the old precedence bits. A TCP implementation strictly
conforming to RFC 793 will not see any change in the precedence
level, even if some packets of the AF flow are marked differently
from others.

Therefore it seems that the diffserv architecture, and all the
PHBs standardized so far, do not break even strictly conforming 
RFC 793 implementations, as long as appropriate traffic conditioning
specifications are configured. Clearly,
some text to document this issue and constrain future diffserv
design work should be included in the next version of the basic
diffserv documents.

   Brian + Kathie

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 30 Sep 1999 12:01:58 -0400

Brian,

I agree with everything you say below, but I think the possible
problem scenario that was raised was when the diffserv environment
_re-marks_ packets. If the DSCP is changed somewhere between ingress
and egress, then how would the egress know to what original TOS
value to set the outgoing packet? In a steady stream, where packets
are potentially being re-marked, _in general_ this could be a
problem.

I agree that the problem might not be realistic today, and that just
setting the TOS byte at the egress to 0 fixes everything, and that
so far the DSCP top three bits aren't changed by AF now anyway, but
these are not the final word. Are they?

(Or maybe they are the final word. The world is full of this sort of
pragmatic solution, after all. It still rotates around the sun.)

Bert
[email-masked]

----- Original Message -----
From: Brian E Carpenter <[email-masked]>

> _______________________________________________
> Diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
>