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

[istoica@EECS.Berkeley.EDU]

Thomas,

----- Original Message -----
From: Thomas Narten <narten@us.ibm.com>
Date: Tuesday, February 11, 2003 6:41 pm
Subject: Re: Experimental RFC to be: draft-stoica-diffserv-dps-01.txt

> > If you say that it is aesthetically ugly to reuse the "ip_off" field
> > then I agree with you.
> 
> You can't sugar coat this by saying it's just aesthetically ugly; it
> is broken. Even if it can be made to work in carefully controlled
> environments, it will almost certainly lead to problems in 
> practice if
> it becomes widely deployed. To make matters worse, the types of
> problems that will show up will likely be intermittant, subtle, and
> hard to track down. In other words, the internet will just become less
> robust and folks won't really understand why.

You might be right that this is broken, but so far the only thing I see
are suppositions. There is no proof that the approach is broken, or at
least I do not see one. All the problems that have been mentioned in the 
previous e-mails are due to misconfigurations. So the discussion in
my opinion reduces to how likely is to misconfigure various routers.
I do not dispute that this is a serious problem in practice, but I don't
think that misconfigurations alone can render an approach as 
"being broken".

Regarding how hard is to track down a potential problem, I beg to differ.
If an egress router doesn't reset the ip_off it would also let the DHCP value 
(corresponding to DSP) unchanged, so any entity that understands
DSP would be able to signal the problem and even recover the packets!

> 
> I personally get frustrated when the internet doesn't work. I at least
> know enough that I can sometimes use tcpdump or other crude tools and
> figure out that something specific is broken and then followup. But
> when I do this, in many cases, the IT folk that have to fix the
> brokeness don't even understand what is going on, much less have any
> idea on what to do about it. When other people encounter such
> problems, 99% of the time they just assume it's something buggy in
> Windows and don't even think to followup. They take it for granted
> that things don't always work right. That isn't what we should be
> striving for. We should be trying to increase rubustness and
> reliability, and by corollary, discourage practices that are 
> likely to
> decrease robustness and reliability.

I certainly agree with your point.

> 
> > However, technically, I still don't see how the particular 
> proposal to
> > use ip_off in DPS is worse than other proposals already in use
> > today.
> 
> What other proposal or practice modifies an existing critical IP
> header field and then claims to restore it safely before delivering
> the packet to its intended destination?
> 
> > Yes, mis-configurations can create problems but the same type
> > of mis-configurations can create similar problems in today's
> > Internet. For example, if an egress MPLS router "forgets" to remove
> > the label, this will confuse the end-host no matter whether the IP
> > header was altered or not!
> 
> Hold on a minute. End-hosts don't run MPLS. MPLS is an L2
> technology. Damage from MPLS mess ups should (in theory at least) be
> restricted to the domain of the L2 cloud. MPLS clouds don't modify IP
> packet fields they aren't supposed to in order to do their thing.

Of course, end-hosts don't run MPLS and I know very
well that MPLS is an L2 technology (actually, more like an 
L2.5 technology because L2 shouldn't perform routing). My point 
was that _if_ the egress router in a MPLS domain forgets to remove 
the label, an end-host can't do anything about it (unless it is MPLS 
aware).

The same thing is true for our approach. If an egress
router of a DPS domain forgets to reset the ip_off field,
an end-host can recover a packet only if it is DPS aware, 
i.e., it knows to interpret the DHCP value assigned to DPS.

The implicit assumption here is that it is as easy 
to misconfigure an MPLS router as it is to misconfigure 
a DPS router. 

> 
> Mucking with the ip_off field can easily push problem 
> determination to
> the edges (i.e., sender and reciever) when end hots are unable to
> properly reassemble fragments. Or something. If the problem can be
> limited to the MPLS cloud, diagnosis is presumably easier. If
> diagnosis of problems falls on the end user (which is what will happen
> if the ip_off field is not properly restored), debugging will likely
> be a nightmare to track down with much finger pointing as to who is
> causing the problem and who is supposed to fix it.
> 
> > Also, a misconfiguration of an ingress filter of a Diffserv Domain
> > can lead to dropping all incoming packets from a specific customer.
> > And, since it appears to me that people are
> > quite successful in mastering the configuration of Diffserv and MPLS
> > today, I don't see why they wouldn't be able (or why it would be
> > harder) to master the configuration of a DPS domain in the future.
> 
> You are relying on sufficent clue to prevent problems. One thing we
> see less and less of is clue. Especially as the internet gets more
> complex and has more interconnections. We should be trying to make our
> protocols work with less clue, not require more.

But the DHCP value is not a clue, or it is as much of a clue as it
is the MF flag!

The main issue here is that it is practically impossible for us to 
convince you that our approach won't create serious problems in 
the Internet if misused. There is no formal model of the Internet
so we cannot formally prove that our approach is safe. This is 
unfortunate because we recognize that ultimately the burden of 
proof is on us.

Given all of these, we will reconsider the use of ip_off.

Ion