Date: Mon, 27 Aug 2001 12:01:18 -0400
From: Alex Conta <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| You know well, I was directly referring to QoS support for IP, i.e.
| network layer protocols.
I know what you were referring to, but I can't think of any good reason
to limit the principle to that, if there were to be such a principle.
That is, unless you're suggesting that QoS protocols are somehow of
magnified status that requires them to be considered where no other
protocol would be?
| However, you seem to contradict yourself - you said earlier "that is
| true".
What I mean there is that it isn't for ipngwg to go look at diffserv,
or intserv, or anything else, and then send a recommendation to the IESG
(or anyone) that protocol X is no good, and should be moved to
experimental, or historic, or something. Especially not when there's
another WG involved.
But that's vastly different than saying that ipngwg (or anyone else) is
compelled to add support in its protocol for any other random protocol.
If the need is apparent enough, then you won't find it hard to convince
the WG of the requirement (like it didn't take much discussion for the
WG to decide that it really needed to support TCP and UDP - on the other
hand (v4) ICMP was discarded and a (similar) replacement invented).
| To have a group of people, within a WG, decide to support with one of
| the protocol functions, (flow label), only one QoS standard, and not the
| other QoS standard, just shows me how the process can go wrong.
I don't see that happening, even if the diffserv arguments aren't
accepted. That isn't the argument that anyone is making.
| There is no concession at all.
Then why are you attempting to argue this bizarre "the WG must do it"
line, instead of just showing on the merits that it is the right thing
to do? If the merits are there, or even if you just believe they are,
that's what you'd be doing, surely - it has to be much easier.
When people start arguing technicalities, and even more, when they're
far fetched unlikely ones, then it is usually a pretty good sign that
they have no substantiative arguments that they find convincing.
| To have to argue at such a length for the full support of Diffserv, to
| have to argue for adding the same level of support as it is provided for
| Intserv, is surrealist, is absurd.
Once again, I am an outsider to this argument, just watching what is
happening. But as I understand it, the "level of support provided for
intserv" is more just that it happens to fit the flow model label use
that the inpgwg has in mind. The use that you want to impose requires more
semantics than the WG might want to load into it.
Pardon my ignorance a minute, let me ask you, and Brian (and anyone
else who knows), a few questions.
It seems that the current flow label is defined to be an immutable field
which should be set to a PRNG to identify flows (related packet streams).
Right?
The only reason for PRNG that I have seen identified, is to allow routers
in the path to use it as a ready made hash, and so optimise their lookups.
Right? Or is there some other reason?
Obviously routers can't rely on that (ie: they can hope for it, and use
it to their benefit where possible, but they can't assume that hosts will
necessarily do the right thing). So, if a host decided to use 1 2 3
rather than PRNG values, the world wouldn't collapse, right?
In response to an earlier question, Brian pointed out that there isn't
really an issue of hoaxing the flow label field to get better service, as
I'd be being billed for whatever service I actually get (if I ask for
good service I get billed more, I assume, and get given good service, even
if by any normal criteria my SMTP doesn't really need it... If I ask for
cheap service, I get it, and poor service as well, even if my video
conference would have preferred something better). Right?
Leaving aside the question of how you know it is me who asked for this
(I assume there's some way of doing this), what I do know is that there's
no way that you can bill me for anything, if we don't have a prior
agreement. Or rather, you can send whatever bills you like, but you're
not going to get paid.
So, I assume there's a relationship between the sending host (its adminstrators
or owners), and the diffserv routers (or their admins, operators, or owners)
Right? (Probably the same for intserv).
Given that relationship, and assuming that the world can cope with any
value in the flow label field, is there any reason that the host and the
diffserv router(s) it is using can't simply agree with each other on the
interpretation of the flow label field? That is, the diffserv routers
say "put this value there, and I'll give you this kind of service".
Where "this number" may be "a number computed by this algorithm using this
input data", for any algorithm that the router & host can manage to
agree upon. The agreement has already been presumed, we're not dealing
with random associations here, right?
To anyone who doesn't understand the diffserv algorithms, that number will
look random - sure, it won't pass any statistical tests on randomness, but
no-one is suggesting that the flow label field is required to contain that
kind of value, are they?
So, why do we need to reserve a bit (or Christian's group of bits) to let
the arbitrary world know what the format of the field is, when it only
actually matters to those who have agreed between themselves how to
interpret it?
Whatever way we go, there isn't space to stick in multiple different labels,
to identify the packet to multiple different QoS algorithms (one for the
first ISP's routers, then a different one for the next, then yet another, ...)
So, we don't need something to allo each to identify what part is meant
for it.
Nor is there a problem of the ipngwg having specified meanings to all of
those bits, which you need to be able to find a way to work around.
ie: we don't need a bit saying "that other interpretation doesn't apply".
They're just a random collection of bits that the sending host can set
however meets its needs.
It seems to me that all that's needed here is for diffserv to go away and
define "For doing diffserv using IPv6, set the IPv6 flow label field as
defined in section P.Q of this document".
That's still meeting the needs of ipngwg as I see them, it isn't compromising
anyone else's uses of the bits, if they're not doing diffserv, and you can
tell the difference, as you have an agreement with the diffserv users
(which you need to be able to bill them) and with that agreement you can
assume they'll use the field the way that you like. If it helps you, by
all means include an "on/off" bit for your algorithm in the definition that
you use, so you can tell which packets (flows) are actually requesting
diffserv service, and which are not.
If the client doesn't abide by the agreement, and starts sending diffserv
looking labels, then you just interpret them that way, and bill them that
way, that's what you agreed with the client to do, after all.
So, it seems to me that there's nothing at all for ipngwg to do here,
other than to continue with the definition of the flow label in its
current form, and not start insisting that the value satisfy any particular
tests of randomness (which would be truly silly, as there's no guarantee
that any particular router will ever see more than one flow label value from
any particular source - and by definition, any value is equally likely if
the number is randomly chosen, so anything goes).
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]
--------------------------------------------------------------------
