Robert Elz wrote:
...
> 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?
The only concrete proposals I have ever seen for use of the Flow Label
are for QOS. Everything else has been hand-waving. We need to decide.
It's unthinkable to leave this big mystery gap in the middle of the
IPv6 header.
...
> 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?
But it is not defined in normative text, and the text we have is vague
on the actual usage - even worse than the text on the TOS byte in RFC 791,
for example.
...
> 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?
Diffserv routers have no relationship with sending hosts; they are
configured within an admin domain (ISP or whatever) according to
local policy. There is no way to agree on anything except global
semantics, and for that to work we need a diffserv-specific format
for the flow label. There simply isn't any other way.
>
> 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?
True, but remember the value is *not* going to be unique-per-host - it doesn't
identify a microflow.
>
> 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?
There is no mutual agreement; diffserv is stateless and has no signalling.
If this isn't reserved in the IPv6 header, a router somewhere downstream
on the data path has to *guess* that the value is a valid diffserv flow
label, rather than an arbitrary value that just happens to have a
diffservish value. That is hardly good engineering.
>
> 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.
This isn't an issue. PHB IDs are globally defined.
>
> 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.
I think I just showed why this is false. The downstream routers must be
able to interpret the bits statelessly, and that means it has to be
an encoded field.
>
> 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".
There is no way we can risk using the flow label for diffserv as it is defined
today, since from a normative point of view it isn't defined at all,
and downstream routers have to guess.
>
> 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)
No, no, no. You have *no* such agreement with the users. You may (or may not,
in theory) have an SLA with your peer ISPs. But the mechanisms are stateless
at each point. You don't know whether a particular traffic source has set
a PRNG value or a diffserv value unless it tells you in each packet.
> 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.
That's exactly the point - that bit has to be defined for *every* IPv6
packet. Otherwise it's guesswork.
>
> 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.
Sure, you will always bill in the way the upstream SLA tells you to. If the
source lies, too bad for the bill-payer.
>
> 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,
If that is the conclusion, diffserv cannot use it and IPv6 will have no
advantage over IPv4 for diffserv.
> 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).
I agree. In the non-diffserv usage, unique-per-source is necessary and
sufficient (with PRNG being a possible optimisation for some router
technologies).
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
