Subject: Re: Flow Label

From: Scott Bradner <[email-masked]>
Date: Wed, 26 Dec 2001 13:57:08 -0500 (EST)

> The traffic field gives the classification. The flow label
> could serve as a proxy for the port number and
> protocol type,

the whole point of class-based QoS is to not have to deal at the
port and protocol level

Scott
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Dec 2001 11:06:09 -0800

Scott,

> the whole point of class-based QoS is to not have to deal at the

Good point, thanx for the clarification.

Perhaps there is some other way to solve the problem, like
uniform agreement among service providers on
diffserv code points and some kind of authentication on the
traffic classification field, so that the service
provider could authenticate that it hadn't
been changed in transit?

But this is perhaps the topic for another
thread and maybe another working group...

            jak

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 26 Dec 2001 13:24:55 -0600

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
> thread and maybe another working group...

Probably a topic for a different Galaxy and StarGate :-)

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Dec 2001 16:01:45 -0800 (PST)

> the whole point of class-based QoS is to not have to deal at the

   Yes, and it almost always means "let's ignore
   admission control" too. Just to make things
   clear, are you thinking of RFC 2996 style 
   reservations or none at all. If the latter,
   all I can say is heaven help us if 911 happened
   on an uncontrolled diffserv cloud.

	Mike

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 Dec 2001 13:31:47 +0700

Date:        Wed, 26 Dec 2001 13:57:08 -0500 (EST)
    From:        Scott  Bradner <[email-masked]>
    Message-ID:  <[email-masked]>

  | the whole point of class-based QoS is to not have to deal at the
  | port and protocol level

But the information about the QoS desired has to come from somewhere
doesn't it?   We assume (as you say) that it doesn't come from the
port/protocol.   It can't come from the traffic class (DSCP), as that's
explicitly been designated to be mutable - when it reaches any random
router it could contain any value at all - not in any way related to
the value it had when the packet left the originator.

So, in your model, from where does an arbitrary router discover the QoS
request desired for this particular packet?

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:18:38 +0100

> the whole point of class-based QoS is to not have to deal at the

That's what I was getting at by saying that the flow label could
have better semantics than port/protocol, if we define it e2e.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:26:02 +0100

James Kempf wrote:
> diffserv code points 

Explicitly rejected by the ISPs at the beginning of diffserv.
That is *exactly* why we need an e2e flow label.

> and some kind of authentication on the

As has been said (*everything* has been said several times
over the last year), it's too late to change AH. In any case,
it doesn't matter: if people change a QOS field to request better
service, they will get it and pay for it; no problem there.

(Theft of service, or DoS by injecting bogus QOS traffic, is
taken care of by admission control at the network edge; nothing
we are discussing here changes that.)

> thread and maybe another working group...

This is old news to the QOS-related WGs.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:31:24 +0100

Michael Thomas wrote:
...
>    admission control" too. 

The diffserv architecture is very explicit that each domain
needs admission control (except maybe for the default class).

>    ...Just to make things
>    reservations or none at all. 

That's by no means the only way to apply admission control.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:46:28 +0100

> request desired for this particular packet?

The specific proposal for intserv usage is to signal the
flow label value in an RSVP Filter_Spec, as part of the
flow setup process.

The specific proposal for diffserv usage is to use
IANA-assigned values, specifically as per RFC 3140. As with
the whole of diffserv, out-of-band configuration is also
rqeuired.

I only mention these answers as existence proofs; there may be other
QOS mechanisms in the future with different answers.

    Brian

---

From: "Perry E. Metzger" <[email-masked]>
Date: 27 Dec 2001 11:21:05 -0500

> have better semantics than port/protocol, if we define it e2e.

Except, absent inducing state in all routers end to end, the flow
label would need to have semantics, not be an opaque token. If it had
semantics, suddenly it becomes the same as the traffic field.

--
Perry E. Metzger		[email-masked]
--
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-masked]
--------------------------------------------------------------------