Brian,
It is obvious we are in violent agreement about how the current
mechanisms work. I think the difficulty arises from the use of
diffserv as a justification for the real goal of exposing the
port/protocol # that ESP specifically hides.
> > This appears to defy logic. The way I read it, we have a QoS
> > mechanism that by-design is not end-to-end oriented, so we MUST
> > define a way for the middle to interpret what the end points
> > are telling each other.?!?
>
> The endpoints in diffserv don't tell each other anything;
> diffserv is an entirely hop-by-hop model. Each hop may choose
> to look at the entire packet header in order to reclassify it.
>
> > There is absolutly no reason to tie the
> > Flow Label field and the Traffic Class field together, which is
> > the only point of defining diffserv semantics for the Flow Label.
>
> No, the point is to provide partial replacement of the {port,
> protocol}
> semantics that are hidden by ESP. There is no tying together of
> Traffic Class and Flow Label. They remain orthogonal.
Yes, diffserv is a hop-by-hop mechanism specifically targeting
the Traffic Class field, but your arguments on this thread are
asking for a part of the Flow Label field for diffserv use, so
you are tying them together. What you stated above though is that
the real goal has nothing to do with diffserv per se, but one of
the capabilities that diffserv based networks typically take
advantage of in the ability to deduce what the application is
doing through snooping the port/protocol #. As I said, you are
looking for a mechanism for the middle boxes to interpret what
the end points are telling each other. Mixing diffserv with the
desire to expose what ESP is hiding is the disconnect. Those
efforts are orthogonal except in environments where people refuse
to trust the DSCP bits but will trust the port # bits. We should
not be breaking the architecture of ESP or the Flow Label simply
to accommodate someone who is paranoid about one set of bits but
trusts another set in the same header!
If the diffserv network really needs to know what the application
is up to then it should use the signaled DCLASS approach of
RFC2966. If it is not willing to go that approach, why are we
trying to explicitly expose what ESP hides? Either they trust the
application to tell them what they need to know through signaling,
or they don't; in which case why would they believe anything in
the Flow Label? If it is simply a matter of domain specific
interpretation of the DSCP has proven to be an operationally
useless concept, then the diffserv group should fix that.
Usurping another set of bits to accomplish what the Traffic Class
field should be used for (but can't for political reasons), is
simply the wrong approach. Your proposal is looking for an exposed
set of bits that will be consistent end-to-end, so people can make
local decisions about how to deliver an end-to-end level of
service through a set of concatenated PHB's (by randomly setting
the DSCP in each domain). Fix the DSCP so those bits are consistent
end-to-end and stay out of the Flow Label field. Its purpose is
for the origin node to identify a set of packets that are related,
nothing more.
Tony
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
