Kre,
Sorry for not answering your message earlier. I was on travel, and I
tackled, shorter messages first.
I left much of your text, which makes the message longer, but makes
easier
to follow the line of thought.
Robert Elz wrote:
>
> Date: Tue, 04 Sep 2001 16:34:17 -0400
> From: Alex Conta <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | Remember, having a Intserv, and Diffserv use of the flow label gives
> | the user the option, and that is a good thing.
> [...]
>
> It is certainly a good thing to allow people to decide whether they
> want to use intserv, or diffserv - but we also have to recognise that
> they're not likely to have a free choice in large numbers of cases.
>
> That is, whether the end user uses intserv, or diffserv, will depend
> upon what is supported between the source and destination of the packets,
> not on which protocol the user happens to thing is best (or most
> suitable for the particular traffic).
Providers are routers/switches users, and they decide what to use in
their networks, i.e. in their routers/switches.
> As described so far, that isn't a problem, as long as the user gets the
> choice to use the protocol that will actually work, that's what is
> important, right?
That's right. The "end-user" users, and "provider" users.
But it is not right to say that "because there is Intserv, that might
work, we must not allow Diffserv, that would also work".
>
> The problem comes because there's no guarantee which of intserv or
> diffserv will be applicable to any particular network. It is entirely
> possible that both will occur between the two end points of any
> connection.
As it is very possible that Diffserv will be used e2e.
> What's more, aside from being extra work for the user
> (the user's system) that shouldn't matter - the user should be able
> to send packets with diffserv classifiers in it, after having requested
> an intserv path from the intermediate systems that support it.
>
> That's why taking the flow label, and saying "this packet is for intserv"
> or "this packet is for diffserv" is wrong - because the packet might need
> to be for both.
>
You are right.
But "is wrong", in fact, applies to RFC 2460, appendix A, i.e. the PRN
number.
You are pointing in fact to one of the main reasons why there was a need
to
define a flow label formatting, or value setting for Diffserv. That is
because
RFC 2460 appendix A, through the PRN rule and some others, excludes
Diffserv.
> Now, I understand that solving the "how do I work with both intserv and
> diffserv" problem is out of scope for basically everyone at the minute,
> and when that is suggested, everyone just says "we're not doing that".
> And that's fine - but we cannot have a solution to anything which by its
> very nature means that a solution to that problem can never be obtained,
> because users are forced to choose (per packet) whether intserv or
> diffserv is to be applied to that packet - with no way at all to say "both".
>
No. In fact it was in our scope, Brian and I, and those who support c),
to have both Intserv, and Diffserv work.
To make Intserv, and Diffserv flow labels work with the same flow label
value on the same sequence of packets is an additional requirement, but
is in my mind, a subset, and it can be resolved, it is just working out
the details. 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.
Our proposal needs more work, we knew that -- to have both Intserv, and
Diffserv work with the same label, Brian and I acknowledged that.
But it is important to underline that "c)" does not exclude Intserv, "
b)" does exclude 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.
> [...]
> Everyone has to
> be able to work with one format of flow label, otherwise we're forcing
> choices that mean too many possibilities are excluded. 10 years from
> now we might know enough about how this is actually used to do that, now
> we simply don't. Nothing more than guessing.
This is an important point.
Earlier, we also got the point that a static separation of the label
space
is not considered optimal, or acceptable by some people on the thread. I
didn't
mind working with the premise that the label space must not be
statically divided.
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.
>
> | As traffic between two end-nodes may have distinct QoS requirements, it
> | is obvious that the information to be given to an infrastructure device
> | must provide the differentiation of the traffic between the two
> | end-nodes.
>
> Yes, this is obvious.
>
> | At an extreme, that information is the
> | transport protocol and source and destination ports, themselves.
>
> That's totally the wrong information, but it doesn't really matter, it
> won't be available anyway - and what matters here anyway is not what the
> actual information is, but that there needs to be some information.
>
You're right. That is in fact, exactly what I meant, which is why I said
"at an extreme".
> There was very little direct reaction to my previous message (Brian's
> need to think about it more was about it), but there seems to be some
> suggestion that an extra header would be too heavyweight, and so be
> too slow to handle.
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.
In fact I was looking for the same efficiency for Diffserv, as that
given to Intserv by the flow label. Additionally...
>
> I can't see how that can possibly be (given what you're willing to allow
> now anyway) ... just imagine that the IPv6 header was 48 bytes long
> instead of 40.
> [...]
> of that for IPv4 - note that the transport header might be buried within
> several layers of IP in IP headers).
>
...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.
> Just at the minute it seems to be (as an outsider) as if people on both
> sides of this debate have become entrenched in their position, and rather
> that looking for a solution that can work, are instead simply set on
> making the solution that they originally conceived into the winner.
>
It is interesting that you perceive it this way.
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.
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.
> Please, everyone, back to the drawing board, come up with some solution
> that is feasible, and can actually work.
> kre
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.
Alex
S/MIME Cryptographic Signature
