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

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

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

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.

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

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.

I also suspect that the the potential failures of this scheme are more
subtle than just blackholing all of a particular customers traffic.

> Finally, let me answer your question regarding how egress routers will
> differentiate between a genuine ip_off and an ip_off used by DPS. This
> differentiation is done based on the DSCP value.

OK, makes sense. This is a side point for me. My concern is really
focused on the misuse of the ip_off field.

> These being said, we are open to revise our draft and address your
> concerns.  However, I would still like to understand what exactly
> makes our proposal "more dangerous" than say MPLS.

MPLS is not the internet. It is an L2 technology of limited
scope. When you muck with IP, you are talking about the real internet
and the scope of potential damage is much wider.

Thomas