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

[Ion Stoica <istoica@cs.berkeley.edu>]

Let me try to clearly state my position and my understanding of the
ongoing discussion at the risk of getting flamed.

If you say that it is aesthetically ugly to reuse the "ip_off" field
then I agree with you. Overloading the semantics of an IP field is not
a clean solution (though redefining the semantics of ToS is not much
better, but I guess in this case you can argue that no one was using
the ToS field anyway). And, yes, this is a valid objection.

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

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. When an ingress
router decides to use the ip_off field it sets a special DSCP value in
the packet header. (Of course, this would require to reserve at least
one DSCP value for DPS, but I believe this is generally acceptable).
The core routers in the domain and the egress routers will only
process packets with the particular DSCP value.

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.

Thanks,

Ion


Thomas Narten wrote:

> > > > 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?
>
> If it's all invisible to IP, fine with me. You are now no longer
> modifying IP.
>
> > 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!
>
> Note also, that if the fragment field is overloaded, you can't have
> any of your internal routers do fragmentation either. Another
> assumption that can't go wrong without bad things happening.
>
> And this is simple? All one has to do to botch things up is to
> misconfigure a router or set up a tunnel from inside to outside
> (oops), etc.
>
> > 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.
>
> Yes. So long as the above is guaranteed. I have my doubts that this
> can be guaranteed. And the more successful the approach is (i.e, in
> deployment), the more likely we will see "misconfigurations"
> happen. When this happens, robustness decreases, and it will be too
> late to undo the damage.
>
> > 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.
>
> MPLS is an L2 technology that sits below IP. AFAIK, MPLS does not
> reuse existing IP header fields for its own purpsoses.
>
> My issue with this document is centers solely on 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 the ingress node. 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 to the next hop.
>
> And, in particular, Section 4.1's recommendation that one use the
> ip_off field of the IP header to hold this state. I do not believe we
> should recommend or endorse any reuse of the ip_off field for any
> purpose other than intended.
>
> I'm fine with using an IP option to encode the state (though I
> understand there are potential deployment issues with that). I'm also
> fine with inserting a shim header between IP and L2. Or any other
> number of approaches. What I gives me heartburn is suggesting that it
> is OK to use fields in the IP header that are already used for
> something else, under the argument that this can be safely
> controlled. I am just not that confident.
>
> Note also:
>
>     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.
>
> One thing that is not clear to me from the above, is how an internal
> (or egress) node distinguishes between a valid fragment (and in
> particular the last fragment, which will have a non-zero offset and
> have the fragment more bit clear) and a "non-fragmented IP datagram
> with DPS information encoded in it". I suspect that any valid DPS
> value one can come up with for the "DPS field" can also correspond to
> a legitimate IP fragment that happens to use the same value. Isn't
> there a collision problem here?
>
> Thomas
>
>