Date: Thu, 06 Sep 2001 01:27:59 -0400
From: Alex Conta <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I left much of your text, which makes the message longer, but makes
| easier to follow the line of thought.
I'm going to try to send one reply to your 2 replies to me, and because
your messages should be just before mine in everyone's mailboxes, and in
the archives, I'll delete most of the context, leaving just the parts I
am directly responding to. (The first 2 messages in the References header
identify the 3 I am replying to directly, for anyone who needs to find them).
| But it is not right to say that "because there is Intserv, that might
| work, we must not allow Diffserv, that would also work".
I don't know who is saying that, but it isn't me. There is some question
about how diffserv needs to be supported, but "not allow" certainly isn't
part of the answer. Nor "not allow" some other new QoS protocol that
hasn't yet been invented.
| That is because RFC 2460 appendix A, through the PRN rule and some others,
| excludes Diffserv.
No, it doesn't allow diffserv type use of the flow label field. That
isn't "excludes diffserv", just alters the way it should be used.
| No. In fact it was in our scope, Brian and I, and those who support c),
| to have both Intserv, and Diffserv work.
That would be good - nd if you can show me a plausible way it could be
done (and ideally, how other different schemes yet to be invented could
also be supported) then I think you'll find that much of the opposition
(from an IPv6 perspective, rather than perhaps internal to how diffserv
does, does not, or should, or should not, work, which is a different
issue entirely).
| To make Intserv, and Diffserv flow labels work with the same flow label
| value on the same sequence of packets is an additional requirement,
Perhaps, but I think an essential one, which hasn't been demonstrated yet.
| is in my mind, a subset, and it can be resolved, it is just working out
| the details.
Yes...
| It may imply some restrictions, like a router cannot use the
| same 3-tuple rule for both Diffserv and Intserv, if the QoS processing
| of the packet after classification is different, which most likely it
| is.
I'm not so worried about the same router wanting intserv & diffserv
classification of the same packet - that would be a pretty silly thing
to expect. But different routers wanting to handle the packet using
different QoS schemes.
| Our proposal needs more work, we knew that -- to have both Intserv, and
| Diffserv work with the same label, Brian and I acknowledged that.
I think that needs to be done before anyone would consider changing the
flow label spec. At the very least you would need a pretty convincing
argument that it can be done.
| But it is important to underline that "c)" does not exclude Intserv, "
As described so far, if the flow label is formatted in the diffserv way,
it seems to me that it does, as a diffserv formatted packet carries the
means for packet classification, where for intserv, the packet needs to
carry the identifier of a previously setup classification scheme. That
is, for any particular traffic type, the former will be a constant, and
the latter will not be. That looks like "exclude" to me. Unless you
can find some other way around that.
| b)" does exclude Diffserv.
b excludes diffserv use of the flow label field, yes - but that's a
different thing than excludes diffserv.
| In reality, nothing other than the using of a Pseudo Random Number (PRN)
| rule, of RFC 2460, appendix A, prevents a node to signal a Diffserv
| formatted label (ala our proposal) as part of a Intserv filter_spec.
No, it doesn't - but there's just one diffserv formatted label for any
particular traffic type, right? It is basically a well known value
(otherwise it would be useless for diffserv classification).
As I understand intserv (which isn't a lot, nor diffserv), a static
value isn't very useful.
| I didn't mind working with the premise that the label space must not be
| statically divided.
If there's been a proposal which avoids that, I must have missed it.
Where was that?
| I would not mind to consider c) as it was, but with the extension that
| flow label is shared to the extent that
| a flow label value must work with both Diffserv and Intserv.
Fine - how?
| In fact I was looking for the same efficiency for Diffserv, as that
| given to Intserv by the flow label.
As I understand it, and do correct me if I'm wrong - that's not really
needed. That is, by your own earlier argument, the flow label should be
used for packet forwarding in the fast path. In diffserv as I understand
it, the bulk of the routers would never be looking at the classifier (the
thing you want to stick in the flow label). Hence, it should not be there,
as it isn't being used for forwarding. On the other hand, for intserv,
every router uses this value - it is truly in the fast path of forwarding,
and hence, by your own earlier argument, its value belongs in the flow label.
On the other hand, I also appreciate that the routers that do do diffserv
classification need to be able to process packets quickly as well, so the
format to be used for the classifier needs to be efficient enough to extract
for that subset of all the routers (what, 4 or 5 maybe in a path length of
30 or so? - assuming diffserv is used everywhere).
[Quoted out of order, wrt getting the value from someplace else]:
| I am not sure if I answered that directly or indirectly. I may have also
| missed your message. But you're right, it is too slow, too heavyweight.
I wouldn't be right in that case, I would be wrong. I don't believe that
it would be, I think you're not understanding just what it is that I was
proposing - but I will reply to that part of the other message stream
(the one that is off the list - which I did, as my original message
contained too much ignorance of what is actually required).
| ...Additionally, because it is the same field in the IPv6 main header,
| for both Intserv, and Diffserv, it allows the use of the same
| software/hardware/silicon classification engine core for both.
That's a good point if it actually gains a lot. I would have thought
that the classification being done, and how it is used, would differ
remarkably between the two, so as to negate that benefit. But who knows,
I don't have much idea what is happening, perhaps I am completely wrong.
But I thought that diffserv was to use this value to access its database
of classification rules, and from that calculate a traffic class (I forget
the acronym you're using for this value now), and then set that in the
traffic class field for future routers in your domain, while simultaneously
using it to decide upon queueing (perhaps routing) strategy for the packet
(just like later routers will do).
On the other hand, intserv is using the value (long with addresses, etc)
to access its forwarding table to direct the packet along a path previously
established (queueing, etc...) No access to the classification database,
that was done before, instead access to a totally different place.
So, while the silicon to actually get the field out of the packet might
be shared, that seems to me to be the easy part of all of this - after that
almost everything is different, until we finally have the "how do I process
this packet" - which has come from elsewhere (different in the two cases),
though it eventually will probably be processed the same way.
I would certainly like to hear from someone who has ever designed silicon to
actually process both intserv, and diffserv, and who has used, or could use,
the ability to share the flow label access to good benefit (something that
couldn't be essentially as easily done with the flow label elsewhere in
the packet).
| I said it many times on this thread, or related threads, that in my
| perception those who want "c)", like Brian, myself, Christian, and
| others, are /looking for/seeking/ a "win-win" situation, that is,
| Diffserv with no excluding of Intserv.
I would like that too.
| Those who want "b)", in my perception, just want to exclude Diffserv
| from using the flow label (at any cost), which is a "win-lose"
| situation.
I think they're mostly wanting to make sure that the current uses of the
flow label aren't disadvantaged by its being given a static value, which
until now has never been really considered. And I don't think it needs to
be a win-lose.
| So, I take your pointing to "c)" ,i.e. that is use of flow label by
| both Intserv,
| and Diffserv, with the caveat of a flow label format & value that can be
| used by both Intserv, and Diffserv.
Show us how that can be done.
| I think that this can be done. In fact, INTServ, could use the current
| Diffserv flow label as long as Intserv allows non-PRN numbers.
Since any value, considered alone, is just as much a random number as
any other value, using a number that happens to be identical to a
diffserv classifier must be OK for intserv. For one flow. For
the next flow however, intserv (as I understand it) would prefer a
different value - even for the same QoS request. diffserv wants the
same value. That's where it seems to get hard to me.
| > Minimise change because people are making hardware today must mean
| > leaving the flow label the way it is in 2460 (or making that text be
| > normative instead of an appendix).
| That is not acceptable because it excludes Diffserv. Something MUST be
| done to have both, and than maximize that (as much as possible).
My comment there was a response to Brian's "minimise change" as a request,
which I suspect he intended as "minimise change to current thinking about
diffserv" but which when treated properly, really would mean exclude
diffserv from the flow label. The point was that "minimise change" is not
what you need to be aiming for.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
