After observing the discussions for some time I'd like
to add my 2 cents on this.
I appreciate Christian's efforts to achieve some concensus
on this issue, but I'd like to add to Jarno's comments below.
What are we doing by allowing multiple uses for the flow
label:
- Perhaps resolving the "conflict" of opinions and getting some concencus
- Creating some conflict in the network, between what the user wants / needs
and the way the network and business models are influencing flow
treatment. How do we solve that ? Negotiation between the host and
network ? compromising one of the two (probably the host/user) ?
- We're opening the door for 15 possible uses of the flow label.
who knows what will happen there !
Are we happy with ending up in situations where the user has to choose
between 2 orthogonal issues like QoS and privacy (just an example) ??
If we are then a split maybe possible, but personally I don't understand
why I should make a choice like that.
At the same time I also understand and appreciate the need for satisfying
the requirements of ISPs and router vendors. It's a matter of deciding
how much should be compromised.
Regards,
Hesham
> While you intended to stay outside of the different QoS schemes, you still
> wanted to cover the intserv/RSVP use of the flow label. Some clarifying
> questions:
>
> Assuming that you proposed intserv to use the label type basic: With the
> label type basic and a non-null label value, are routers supposed to do what
> you propose regardless of the presence of intserv state? I.e. to nail down
> the path even if intserv is not used?
>
> Could routers not interested in QoS classification based on the flow label
> at all (e.g. diffserv interior routers) safely use just the 16 bit label
> value for path distribution (ignoring the label type)?
>
> With the current flow label semantics the routers can avoid doing intserv
> state lookup if the flow label is null. If the flow label is used for path
> distribution, the router will be searching for the intserv state for all the
> packets (assuming the router does intserv at all). So from this
> point-of-view it might be better to designate a separate label type for
> intserv?
>
> Or maybe intserv should be able to use whatever label type it wishes. Some
> other type could allow for example rewrite at the intserv domain egress,
> allowing the flow label to be mapped a value meaningful for some other
> QoS/forwarding domain. (The value itself could be either carried in RSVP or
> decided by the SLA between the intserv domain egress and the next domain).
>
> What I'm aiming at is to see if a classifying router (intserv, diffserv, or
> other) could be ignorant of the different flow label types when doing the
> lookup based on the 3-tuple of the source address, destination address and
> the 20 bit flow label. What state is then found based on the lookup would
> tell the router what to do with the packet (which flow it belongs to, how to
> police it, queue it, possibly remark DSCP and/or flow label, which interface
> to use for output, etc.). In this scenario all the difference of the
> different label types would be in the control plane (i.e. population of the
> state found by the lookup engine). The silicon doing the classification
> would remain the same regardless of the label type.
>
> Or will the definition of the label type result in specialized silicon for
> the different type values?
>
> Jarno
>
> Christian Huitema wrote:
> > I hope that after three weeks of exchanges, everybody is
> > convinced that
> > we will not get any consensus on whether the best handling of QoS is
> > diffserv, intserv, or maybe no QoS at all. Let's try to be
> > practical. We
> > have a simple problem to solve, the definition of the flow
> > label in the
> > IPv6 specification. I propose the following compromise:>
> >
> > The flow label is comprised of 20 bits, divided between a
> > four bit label
> > type and a 16 bit label value. IPv6 sources may set the flow
> > label type
> > and the flow label value to label sequences of packets for which they
> > request special handling by the IPv6 routers, such as non-default
> > quality of service or "real-time" service; the label type defines how
> > the label value shall be used in the production of these services.
> > Label types may be defined in IETF standards and registered with the
> > IANA. This specification (i.e. IPv6) defines only one label type, the
> > basic label, whose value in binary is 0000. Sources that do
> > not require
> > any specific service should set the label type to the basic label and
> > the label value to a null value.
> >
> > When the label type is the basic label and the label value to
> > a non null
> > value, IPv6 routers are expected to treat identically all packets that
> > carry the same source address, destination address and flow label. For
> > example, when traffic is load balanced along several alternate paths,
> > these packets should all sent on a single path; when classification is
> > performed for the purpose of quality of service, these packets should
> > all be classified in the same class. If the label type is set to the
> > basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label
> > value.
> >
> > Processing of the flow label, and possibly rewriting of the
> > label value,
> > is specified in the IETF standard defining the label type.
> > When a router
> > encounters a packet with an unknown flow label type, it
> > should treat the
> > packet as if the label type was the basic value and the label
> > value was
> > the null value. Routers SHOULD NOT rewrite or alter the flow
> > label value
> > if the flow label type is unknown.
> >
> > I believe it captures most of our discussions: we get a basic
> > label that
> > is roughly equivalent to the label currently assumed by
> > RSVP/Intserv; we
> > get reserved bits for the future generations; and we get an extension
> > mechanism that can possibly used by Diffserv, charge to them
> > to describe
> > exactly how they intend to use it.
> >
> > -- Christian Huitema
> >
> > --------------------------------------------------------------------
> > 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
