Robert Elz wrote:
>
> [...]
> | 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's correct.
>
> | 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) [...]
>
> [...]
>
> | Our proposal needs more work, we knew that -- to have both Intserv, and
> | Diffserv work with the same label, Brian and I acknowledged that.
>
The above "the same label" was meant "the same label space". As a
further clarification,
it means to work on removing a static separation of the flow label
space.
> 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.
>
Your statements suggest that any specification of the use of the flow
label with
Diffserv must work with the use of the flow label by Intserv, and any
other possible
schemes to be invented...
In principle, and I said this before with other words, I do not have
trouble with a standard in which both Intserv and Diffserv can share the
same label space, and
therefore the same label.
But I should say that I am troubled, if the standard is not applied
fairly, and equally
on both sides.
Your statements above, and implicitly anything supporting them, I am
afraid, create a double standard, don't you think?
One, in which it is OK that the specification of the use of the flow
label with Intserv,
in Appendix A of RFC 2460, which, by requesting the use of a
Pseudo-Random Number,
excludes currently the use of the flow label by Diffserv, which back in
94-95, 97-98, was "a possible scheme that could be invented in the
future".
The other, in which any specification for the use of the flow label with
Diffserv,
MUST work with a Intserv flow label, and anything that could be invented
in the future.
> | 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.
According to the proposal, there is a separation of label space. That
ensures
that the use of the flow label with Intserv, and Diffserv do not
intersect, and
therefore, in light of the AD's clarifications regarding normative,
non-normative text,
there is not need to change "appendix A", in RFC 2460.
>
> | 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.
Why not?
>
> | 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.
I correct you.
> [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 was answering your statement "but there seems to be some suggestion
that an extra header would be too heavyweight, and so be too slow to
handle"
So, you were right, there were such suggestions. But please do not
misunderstand me,
if it is a good approach, please write it up.
> 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).
I thought that as a Hop-by-Hop header option, only for Diffserv, it is
not going
to provide the same efficiency as the flow label, a fixed size field at
a fixed
offset in the main header, and the advantage of using the classification
engine
for both Intserv and Diffserv. I replied to you in more detail, with my
observations,
in a private message.
>
> | ...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.
>
I think this was mentioned at least a couple of times, by a couple of
people, besides me, on adjacent threads, or this one, for instance Frank
Kastenholtz.
>
> 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
You just heard it (-:.
>
> | 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.
Even though we knew it does not really matter whether the flow label
value is PRN or not, it is exactly why Brian and I put out a proposal
that would not change the PRN rule for the Intserv use of flow label --
the proposal of a static separation of the flow label space.
But again, I am quite concerned by the double standard being suggested,
and in fact, applied (see above).
> And I don't think it needs to
> be a win-lose.
>
This is a very positive step.
> | 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.
>
For Diffserv, for a different flow, between the same two end-nodes as
the previous
flow, there is a need for a different flow label value. For a different
flow, between two end-nodes that are different than those of the
previous flow, the flow label value can be the same, or can be
different.
> [..]
> kre
Alex
S/MIME Cryptographic Signature
