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

[Bob Braden <braden@ISI.EDU>]

Hi.  I would just like to inject an opinion about this document,
speaking *as chair of the E2E RG of the IRTF*.

The IESG (Thomas) wrote:

  *> 
  *> 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.

I believe that diffserv already breaks the "end-to-end properties of
IP" by rewriting DSCPs, and that diffserv changed the historic meaning
of the TOS field in such a way as to potentially break existing uses.
DCP promises no worse.

The IESG and the community made the judgment that the advantages of
diffserv, namely (limited) QoS without per-flow state, justified this
modification of the architecture.  Experimental deployment of DPS may
or may not show it to be Computer Sciences gift to QoS, but it does
claim to offer real QoS without per-flow state, a significant gain that
would certainly justify minor downsides if realized.

  *> 
  *>   > 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.
  *> 

"Serious damage" seems a bit exaggerated, but in any case, DSP offers the
possibility of providing serious gain to the Internet and its users.  It
might keep the telcos from imposing something you will like even less,
like the circuits waiting in the wings!

  *>   > 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.
  *> 

I suggest that this statement should at least be open to discussion.

  *>   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
  *> 

This document seems to define an important and perhaps useful piece of
Internet research, which might help solve a problem that the IETF has:
QoS.  You can't have progress without at least some minor risks.

Or maybe the IESG would rather mandate RSVP and Intserv. ;-(

Bob Braden (as chair of the E2E RG of the IRTF)


PS: Should this discussion be in public on the IETF list?  It's OK with me.