Michael Thomas <[EMAIL PROTECTED]> writes:
> Perry E. Metzger writes:
> >
> > Michael Thomas <[EMAIL PROTECTED]> writes:
> > > If you don't believe in signaled QoS, you don't
> > > believe in any use of a flow label qua flow label.
> >
> > I thought we had a "traffic class" to permit "signaled QoS" for some
> > value of "signaled QoS". I was unaware flow labels were intended for
> > this purpose.
>
> DSCP's aren't guaranteed to be end to end.
And what does that have to do with the "traffic class" byte in the
IPv6 header?
> > I'm an old fashioned kind of engineer. I'd like to see some folks from
> > router vendors give us precise information about the *exact* use
> > they'll put the flow label information to, and quantitative
> > information about how much better it will be for them to have the flow
> > label than not to have it. Engineering by committee is bad enough --
> > engineering by committee and by hearsay simultaneously is far worse.
>
> If we want to future proof some of the bits,
> we can reserve 2 or 4 bits and make 0 be
> this definition. This is *hardly* a new and
> unexpected semantics fo the flow label.
All you're doing is saying "we can afford to waste the bits". Fine. I
don't care about the bits. Can we afford to waste the time writing
code that doesn't help anything? Repeating, I'd like to see evidence
that we actually are going to have a benefit from doing this work.
> Indeed,
> it's seems to be all of the hangwringing over
> the obvious definition for these bits that
> has managed to shoot IPv6 in the foot, re
> fast flow clasification.
There isn't a flow label in IPv4 and it seems to be well deployed.
> But I'm not sure what you're asking for.
> Do you really have any doubt that forming
> the flow key from fixed postions in the
> IP6 header is going to not kick butt on
> chasing down header chains with a half
> dozen different rules dependent on protocol
> value to hopefully find a 5 tuple?
Yes, I have substantial doubts on this. First of all, people already
have silicon that does this astonishingly fast. Second of all, they
don't yet have silicon that will do anything with the "flow label" and
it will be years before they could have deployed hardware like
that. Third, they'd have to chase down the header chains anyway,
because stuff like XP isn't going away. (In other words, we've
deployed, it is too late.) Fourth, I have yet to see any real
explanation of what this is going to do for people in
practice. Repeating my earlier request:
I'm an old fashioned kind of engineer. I'd like to see some folks from
router vendors give us precise information about the *exact* use
they'll put the flow label information to, and quantitative
information about how much better it will be for them to have the flow
label than not to have it. Engineering by committee is bad enough --
engineering by committee and by hearsay simultaneously is far worse.
> Yeah, yeah, some (edge) routers will have to do that anyway, but
> this is *such* a no-brainer for the host that they deserve lousy
> (degraded) service if they can't be bothered to implement either
> diffserv or setting flow labels.
If it is such a no brainer, I'm sure it would be easy for you to
explain, as I've asked:
1) What exact use you will put the flow label to
2) Precisely what quantitative improvements you're expecting over
existing hardware classification mechanisms by having the flow
label.
When I hear folks at Juniper mumbling that they already have their
hardware v6 support out in the field in their existing router line,
and I hear folks from Extreme mumbling that they have their packet
classifiers built (and they're hardly the only ones), and I look at
the fact that there are a whole lot of v6 enabled systems already out
there in the field that aren't going away, I feel like I have to start
asking hard questions.
If we're going to start mandating people do something new at this late
stage of the game, we'd better have a good engineering rationale for
it, along with good measurements to back up that rationale.
--
Perry E. Metzger [EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
