The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Shahram,

	A few people pointed out that there is a draft
(newer than the one listed in the MPLS-DiffServ
draft) which I had missed earlier on the web page
for DiffServ working group drafts.

    http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-01.txt

This draft does define Uniform and Pipe models.  I
read the part of this draft that defines these two
models and still am not sure why the Uniform model
is needed, but I assume that there has been a lot
of discussion on this on a mailing list which I've
admittedly paid less attention to (though a quick
screening of the mail archive only turned up one
comment on the topic in the last 9 or 10 months).

	However, now that I know where this comes from,
I am even more convinced that this should be treated
as out of scope for the MPLS DiffServ draft.  My
thinking is based on the considerations that the draft
on DiffServ tunnels is only in its second iteration as 
a working group draft (and may be relatively immature)
and was downgraded (from a standards track draft) to an
Informational RFC track document just a few days ago.  
The current level of maturity for that draft means that 
it is possible that one or the other of the two models 
may still be removed and the fact that it is now meant 
to be informational means that there is less incentive 
for working group members to expend effort to ensure 
that it accurately reflects what the implementers are 
really implementing and the users are really using.

	That draft currently assumes that the DS field is
strictly copied (from inner to outer on tunnel ingress
and from outer to inner on tunnel egress).  Clearly,
the restrictions imposed by mapping the DS byte to the
smaller EXP field (or DE/CLP bit) means that there may
not be a consistent way to "copy" this information from
one label to another.   However, this fact means that 
the process of mapping one value to the next will most
likely result in information loss.  This information
loss will most probably lead to degradation in service 
intended for DiffServ labeled packets - since it seems 
unlikely to be a good policy to always upgrade service 
in this case.  Consequently, the Uniform model is very
unlikely to be useful when it is not possible to copy
EXP bit values from one label to another.

	On top of this, the discussion I expected to see
in the DiffServ mail archive was a discussion of the
consequences of 'punishing' packets that have made it
through a tunnel successfully by carrying forward any
degradation in their service that may have occurred 
while transiting the tunnel.  Typically there is some
cost associated with tunneling packets and this is a
'sunk cost' once the packet has succeeded in making
it through the tunnel.  It then seems a little strange
to drop this packet at a congestion point when it was
not dropped within the tunnel and would not have been
dropped if it still had the PHB it had on entering the
tunnel.  This may be a 'belief system' issue but, when
combined with the likelihood of losing information in
mapping (as opposed to copying) EXP bit values from
one label to another, there seems to be less reason
to explicitly specify this behavior in MPLS DiffServ.

	Minimally, the draft needs to say a lot less on
the subject of the two models in order to avoid being
locked into a position in which it 1) cannot be moved
forward until the DiffServ Tunnels draft is progressed
and 2) is inconsistent in its usage with that work.

--
Eric Gray