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.
Actually, no it isn't, the way it is being proposed anyway, it is
a horrible thing indeed.
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).
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?
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. 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.
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".
Having a bit in the flow label that says "this is diffserv" or "this is
not diffserv" or "this is a microflow identifier (prng)" or "this is a
static classifier" (which amounts to the same thing) if forcing that
choice, and leaving no room at all for "both". 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.
| 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.
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 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. And instead of one bit to say diffserv or not, that
you seem willing to test, there are 8 bits that need to be set to a
particular value (sure that's more gates to do the test, but testing
8 bits for a particular value is one of the simpler pieces of logic to
design..., and is no slower than testing 1).
As long as those bits say that the diffserv QoS info is there, then it
would be at a fixed position relative to the start of the packet.
Just somewhere between byte 40 and 48 instead of somewhere between
byte 0 and 4. Big deal. To compensate for the extra delay while the
extra bits arrive, you get more information to use.
What's so heavyweight about that? I wasn't proposing anything that would
require chasing header chains to find the data, and extracting it from some
arbitrary position (though diffserv seems able to do the rough equivalent
of that for IPv4 - note that the transport header might be buried within
several layers of IP in IP headers).
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.
Please, everyone, back to the drawing board, come up with some solution
that is feasible, and can actually work.
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]
--------------------------------------------------------------------
