[EMAIL PROTECTED] writes:
I am traveling and cooling off, a little bit is not bad. Apologies for bad
formatted text.
> I gave myself 24 hours off from this thread to draw breath. Here are
comments on a bunch of points from various people.
> Speak to your co-author who keeps insisting that they are
> mutable.
Yes, and I think I disagree with him :-)
We cannot change checksum and authentication calculation anyway.
I would be happy with an adequate language.
> In any case, the point is that for diffserv to work there
> has to be a visible set of bits that are immutable end-to-end
> with well-known semantics. Currently that is the protocol/port,
> simply because ESP wasn't in widespread use. In IPv6 we assume
> it will be, so diffserv needs another set of bits that have an
> immutable well-known end-to-end semantic.
Well, Alex is correct to the extent that "immutable" is not an
absolute requirement; "globally defined" is necessary and sufficient.
But as just stated, I prefer immutable.
Let's not make the language and the rules stronger that they need be.
We can write in a language that it does the job for everyone.
Alex Conta wrote:
> .
> [...]
> The flow label bits were mutable, the meaning was immutable.
Yes, it *could* work that way but I would argue against it - I'd much rather
keep it simple and have the flow label immutable.
To me "immutable" means the bits are "read-only". Let's work on the
language, that would be satisfactory to everyone. It would look like a
silly, technical weakness, to have a field as read-only,
but with no mechanism for the final recipient to detect whether
it was changed or not.
[EMAIL PROTECTED] wrote:
...
> > That's an interesting thought, but I think it doesn't work.
> > The egress router
> > has to *know* that the flow label is in diffserv format, and
> > I think that
> > requires some magic.
> >
>
> Wouldn't the absence of intserv state for the flow at the domain egress be
> the magic for this determination?
That's an interesting thought.
if flow label != 0
and there is no intserv state
then try diffserv classification
This needs a little thought but it looks hopeful to me.
These are indeed good ideas.
We can iron out the details, to make the flow label space
allocation dynamic, and the flow label format transparent.
This way the space is used according to the users needs
(customers/providers),
and the hardware/software classifier can be easily shared.
> > > The set of packets identified as a
> > > flow will be the same with either QoS mechansim, so why is there
> > > a need to have distinct semantics unless someone in the middle wants
> > > to interpret them?
> >
> > Diffserv is blind to microflows; there is no flow identification.
> > However, diffserv classifiers in the middle *do* need to (re)interpret
> > packet headers. That is how diffserv works.
>
> I'm afraid that this makes no sense at all.
The point is that the diffserv low level scheduling mechanisms are
driven entirely by the 6-bit DSCP field and that is the only
thing that core routers look at. That's what we mean when we
say diffserv is blind to microflows. The edge classifiers are
also very unlikely to be microflow based; although they use 5-tuple
classifiers, we expect the addresses and ports to be ranges or wild
cards in most cases. In fact it would be quite unusual for a
diffserv classifier to look for a specific microflow rather
than a large class of microflows.
Even though it may be the case, I would not prohibit a classification
on all fields. That gives a lot of flexibility to the users
(custmers/providers)
in particular since the guts of the classifer mechanism allow for both
Intserv, and Diffserv M-F classification.
> I hope that if we'll have the flow label support for what Brian is asking
> (standard, non-mappable behavior aggregates), he'll promise to remove the
> MF-classifiers peeking into transport headers from the diffserv specs :-)
> (also from the non-ESP case).
That's not going to happen.
But it is likely that practically, as IPv6 would use flow label classifiers,
the need
to use, and with that the practice of snooping at the transport headers would
desappear.
Brian
