Robert,
Very well put! Just some additional thoughts:
- If diffserv WG so wants, it can even define a specific (standard) DSCP
value to be used between domains to signify that the flow label in the same
IP header has "diffserv semantics". This way the classification could be
done the same for all source addresses (otherwise ingress router would need
to know which source addresses use diffserv semantics for the flow label?).
- If there is a diffserv relationship between a client and an ISP, the
client could still use intserv for select flows by doing intserv signaling,
which would explicitly tell the ISP that the associated flow label does not
have any diffserv semantics.
Jarno
Robert Elz wrote:
...
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
