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

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

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