Re: Experimental RFC to be: draft-stoica-diffserv-dps-01.txt

[Ion Stoica <istoica@cs.berkeley.edu>]

I'd like to answer the objections regarding the fact that
DPS would violate e2e properties of IP.

DPS can be implemented in several ways:

1) use an IP option

2) use a label between layer 2 and layer 3 (like or
in conjunction with MPLS)

3)  Use PHB codepoints and ip_off field.

I don't think there are questions with respect to
methods (1) and (2) as they are already in use today.

With respect to (3) note that we propose
to use only PHB codepoints which are not allocated
yet and ip_off filed, but only if this field is zero. Furthermore,
ip_off is restored to zero when it exits a DPS domain.
If ip_off is not equal to zero, ip_off is *not* modified
(i.e., these packets are ignored by DPS).
Thus, what happens in a DPS domain is completly
transparent to end-hosts. So, I'm not sure how
would this affect IP e2e properties. (Obviously,
I'm ignoring here bugs, which I agree, can be
a serious issue in practice).

In summary I have two questions:

- Would it be possible to get a more specific
  reason of why DPS would break IP?

- If the answer to the previous question is
  conclusive and positive, would it be then
  acceptable to publish the RFC using methods
  (1) and (2) to encode the state?

Thanks,

Ion


Jacqueline Hargest wrote:

> Sandy,
>
> The IESG requests that Per Hop Behaviors Based on Dynamic Packet State
> <draft-stoica-diffserv-dps-02.txt> NOT be published as an Experimental
> Protocol.
>
> This document includes the following:
>
>   > With Dynamic Packet State, each packet carries in its header, in
>   > addition to the PHB codepoint, some PHB-specific state. The state
>   > is initialized by an ingress node, when the packet enters the DS
>   > domain. Interior nodes process each incoming packet based on the
>   > state carried in the packet's header, updating both its internal
>   > state and the state in the packet's header before forwarding it.
>
>   This is a potentially serious violation of the end-to-end properties
>   of IP, as it proposes reusing existing IP header fields for other
>   purposes than intended. Use of these techniques can result in
>   incorrect processing of IP packets as a result of information loss
>   occurring when existing IP header fields are reused for alternative
>   purposes.
>
>   > By using DPS to coordinate actions of edge and interior nodes
>   > along the path traversed by a flow, distributed algorithms can
>   > be designed to approximate the behavior of a broad class of
>   > "stateful" networks.
>
>   This scheme can only be safely used if packet fields are restored
>   properly in all cases. However, it is easy to imagine scenarios where
>   this property will not be honored, and the result will be a less
>   reliable Internet. Deployment of such systems have the potential for
>   causing serious damage to the Internet.
>
>   > In this respect, we observe that there is an ip_off field in the IPv4
>   > header to support packet fragmentation/reassembly which is rarely
>   > used. For example, by analyzing the traces of over 1.7 million packets
>   > on an OC-3 link [nlanr], we found that less than 0.22% of all packets
>   > were fragments. In addition, ther are a relatively small number of
>   > distinct fragment sizes. Therefore, it is possible to use a fraction
>   > of ip_off field to encode the fragment sizes, and the remaining bits
>   > to encode DPS information. The idea can be implemented as follows.
>   > When a packet arrives at an ingress node, the node checks whether a
>   > packet is a fragment or needs to be fragmented. If neither of these
>   > is true, all 13 bits of the ip_off field in the packet header will be
>   > used to encode DPS values. If the packet is a fragment, the fragment
>   > size is recoded into a more efficient representation and the rest of
>   > the bits is used to encode the DPS information. The fragment size field
>   > will be restored at the egress node.
>
>   As a specific example, the above will fail in some circumstances. This
>   would be unacceptable for general or wide deployment and cannot be
>   recommended.
>
>   Given the potentially serious negative consequences of deployments of
>   the techniques described in the document, the IESG does not believe
>   this document should be published as an RFC.
>
>         Thomas Narten for the IESG