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

[Thomas Narten <narten@us.ibm.com>]

Ion Stoica <istoica@cs.berkeley.edu> writes:

> 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

Use of IP options in IPv4 is generally considered a non-starter. You
get slow processing, each router has to muck with the packet, hard to
deploy, etc.

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

But then this is all happening below IP, and doesn't need to include
modifying the IP header. Right?

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

It is bugs and "not supposed to happen" things that I worry can harm
the internet. It is use of the ip_off field that concerns me.

> In summary I have two questions:

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

Can you guarantee that e2e won't break? I don't think so, and that
worries me. I don't see the benefits of this approach being large
enough to justify encouraging use/experimentation with techniques that
run the risk of causing basic IP mechanisms to stop working as
intended.

Let me pop up a level. Why do you want to publish this as an RFC? I
think these sorts of things are fine for research publications. But I
don't see why an RFC is needed.  I don't see this as something that we
necessarily need to encourage experimentation with in the bigger
Internet. What concerns me the most is reusing existing IP header
fields under the claim that you will always a restore them back before
they reach their ultimate destination. I fear that this is wishful
thinking and will be too hard in practice to ensure.

Thomas