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

[istoica@EECS.Berkeley.EDU]

Thomas,

First of all thanks for the comments. Please
see my answers below.

----- Original Message -----
From: Thomas Narten <narten@us.ibm.com>
Date: Monday, February 10, 2003 10:40 am
Subject: Re: Experimental RFC to be: draft-stoica-diffserv-dps-01.txt

> Ion Stoica <istoica@cs.berkeley.edu> writes:
> 
> ...
> 
> > 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?

That's correct. Would this be ok?

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

I'm afraid I do not understand why this would be the case.

This can happen only if the eggres node of a DPS domain
"forgets" to reset the ip_off value to zero and update the IP checksum.
But this is a very simple operation, and I don't see many ways one 
can get it wrong! 

As long as a DPS domain resets ip_off, the action
of a DPS domain on IP packets is completely transparent e2e.
A packet enters with ip_off=0, and exits with an ip_off=0. No other
fields (except for DHCP extension bits) are modified. This is no
worse than Diffserv.


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

Again, please see my comment above. Because this operation
is so simple, we believe that it shouldn't be a problem to get it
right in practice. Also, I do not see how this is worse than
MPLS. With MPLS, if the egress router doesn't remove the label, an
end-host will get confused.

Anyway, maybe I'm still missing something. Please let me know
if this is the case.

Thanks,

Ion