Subject: Re: Flow Label

From: Scott Bradner <[email-masked]>
Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST)

all you're saying
   here is that you don't believe in Intserv/RSVP. 

I did not say that at all

I do not believe that there is currently any way to deal with the 
*business* and *operational* issues of asking some remote ISP
to provide QoS service for you in any sort of scalable way

please do not read into what I say any more than I actually say

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: Michael Thomas <[email-masked]>
Date: Wed, 2 Jan 2002 12:20:59 -0800 (PST)

> to provide QoS service for you in any sort of scalable way

   Fine, but that's completely orthogonal to whether
   the flow label is a good idea or not. Only by placing
   a value judgement on the supposed intractability of
   that problem does it effect the outcome here. As in,
   if you don't think it's solvable, it would obviously
   be throwing good bits after bad. If you're in the
   "don't know" camp -- as  I suspect many people are --
   I think we can easily reserve a few bits and state that
   the flow label only applies when the reserved bits
   are zero and that all other combinations must be
   ignored.

		Mike

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Jan 2002 12:36:59 -0800

> Fine, but that's completely orthogonal to whether the flow label is
> a good idea or not.

we don't care that no one can operationally use it.  if it might sell
one more router, let's kludge up the net a bit more.

randy

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Jan 2002 12:43:39 -0800 (PST)

> one more router, let's kludge up the net a bit more.

Oh, please. There is a very straighforward tweak
to RSVP to support this, and this is an
*anti*-kludge since the original kludge was
overloading the use of L4 information for QoS.

I'm not aware of anybody at my employer salivating
at the revenue potentials for a newly defined flow
label.

		Mike

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Jan 2002 12:49:04 -0800

> Oh, please. There is a very straighforward tweak to RSVP to support 
> this

i anxiously await a description the tweak which will provide "any way to
deal with the *business* and *operational* issues of asking some remote
ISP to provide QoS service for you in any sort of scalable way."

randy

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Jan 2002 12:53:52 -0800 (PST)

> ISP to provide QoS service for you in any sort of scalable way."

   Different problem. No cigar. This bait and switch
   reminds me of the same sort of tactics of those
   who endlessly pointed out that ip6 didn't solve
   the route explosion problem. As in, duh.

	     Mike

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Jan 2002 12:02:54 +0700

Date:        Wed, 2 Jan 2002 14:22:28 -0500 (EST)
    From:        Scott  Bradner <[email-masked]>
    Message-ID:  <[email-masked]>

  | I do not believe that there is currently any way to deal with the 
  | *business* and *operational* issues of asking some remote ISP
  | to provide QoS service for you in any sort of scalable way

Yes, that's a real hard problem.   But it isn't the current one.

There are two separate issues here - how to communicate the information,
and then how to use it.

Now it is certainly true that communicating information is a waste of time
if the information can't be used -- but it is also true that there's no
point figuring out how to use the information if there's no way to communicate
it.

Since the operational issues are hard, without doubt, there's a certain
reluctance to attempt to find a solution to it - and as long as that can
be avoided by resorting to "we don't need it yet, there'd be no way to use
it anyway", that is what will keep happening.

But there is a simple solution which can arise - I, as a customer, can work
out what path my packets will take (AS path), make contact with all of the
ISPs represented, and offer to pay them large amounts of cash to make some
specific set of my packets get to some particular destination(s) much more
reliably with much lower than normal (congested) delay.   That's easy to do
(assuming the availability of the cash).   It can be done today.

However, assuming I do that, how are all those ISPs supposed to implement
my request?   Currently they'd have to do it using port number snooping,
and so I'd have to be able to specify the port numbers in advance.  But
that's not always possible, nor is it a rational design in any case (it
just happens to be all that's probably possible with IPv4).   With IPv6
I can simply arrange to label all the "important" packets, so all those
ISPs, who are only too willing to accept the cash, can actually manage to
earn it.

Now of course, as an operational method, the one above doesn't scale at all.
But that's OK, it doesn't have to - it isn't being proposed as a method
to be adopted by all and sundry.  What it has done is provided the
motivation for the mechanism to exist that allows the packet classification
to be reasonable.   Given that, the desire to make use of this will grow,
and the operational community will be forced to do the work to figure out
how to make it feasible economically.

This may end up falling back to explicit agreements between sender
(or receiver) of the data and everyone along the path (as in a credit
card number included in the RSVP reservation packet, or the equivalent)
Or it could be done based on settlements between ISPs, with the ISPs
perhaps using the DSCP in packets passing between them to indicate:
"I am being paid more to achieve better results for this packet, it will
offset as more than a normal packet if you also give it priority" with
most likely, each ISP subtracting a little from the amount offered as
their own compensation, so the sender would need to offer more to get
priority through a long path than through a short one (which is entirely
reasonable).  Or it could be something quite different.

I don't think it is for this working group to answer that question.
I do think it is reasonable though for enough basic mechanism to be
provided that the ISPs can actually process the packets reasonably
though - and I think now that we know enough about how the protocol
parts of all this can be made to work (as aside from the operational
issues) that it can be done now - and so provide the rationale for
actually doing the operational work.

Chasing down header chains looking for a transport header certainly
isn't the answer (even considering ESP headers as transport for this
purpose, which I'm not sure I'd regard as correct anyway).  Unlike
in IPv4, there's no guarantee that the transport header will even occur
in the first fragment of a large packet in IPv6.   While it might seem to
be folly to send fragmented packets at the IP level and expect any kind
of quality of service, with IPv6 it really isn't.   If the amount of
data that has to be delivered (whether that be transport data, or
additional data from extra "headers" is larger) than will fit across the
path MTU, then some kind of fragmentation is required.   Whether that's
done at the IPv6 layer, or at the transport layer (with some kind of
segmented messages) doesn't really make any difference - all the pieces
need to arrive for the data to be interpreted (that's an assumption).
In a scenario like that, it makes perfect sense to use IPv6 fragmentation.
And if that's done, the port numbers (or even ESP SPI) might not be in
the first fragment.  This cannot disqualify the packet from receiving
any kind of QoS treatment.   With IPv6 there is no need for it to do so
either - everything needed to classify the packet is in the IPv6 header
(addresses and flow label).   That's all routers should be looking at, as
it is all that they can reliably expect to actually find (even ignoring the
issue of "find quickly").

kre

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Jan 2002 21:19:59 -0800

> Now it is certainly true that communicating information is a waste of
> time if the information can't be used -- but it is also true that there's
> no point figuring out how to use the information if there's no way to
> communicate it.

<curmudgeon>

the ietf is becoming full of mechanisms of little use.  yet there remain
some very hard but useful and known to be usable problems to solve.  can
we spend our energies on these?

on the other hand, there is the theory that it is better that idle hands be
occupied with useless but non-damaging work lest they find damaging things
to do.  the problem with this approach is that the router code bases are
unreliable and unstable.  any unneeded additions will only make them worse.

randy, a big fan of mbz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Jan 2002 17:18:58 +0100

Randy,

The proposed new words for 2460 effectively say
- you don't have to set it
- you don't have to look at it
- you mustn't change it

I don't think encourages kludge significantly more than MBZ text, but it 
does allow for future usage.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Jan 2002 17:26:30 +0100

The one acronym summary of kre's point is: SLA. I'd venture
to say that no QoS solution will ever work in the absence of
an SLA. And guess what, the IETF doesn't discuss business
models and SLAs. The most we can do is standardise tools
that can be deployed to support SLAs.

So, I think it's time for a hum on this one (the simple
update to 2460 that Scott and I at least seem to agree
on).

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Jan 2002 11:31:14 -0500

>update to 2460 that Scott and I at least seem to agree

Hum.

Could someone publish an internet draft with this wording?
The only draft that we have now is pretty far away from this.

Margaret

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 03 Jan 2002 09:02:30 -0800

Hello Brian et.al.,

> update to 2460 that Scott and I at least seem to agree

Although I have not participated in this discussion, I have
followed it closely.  I like the simple update to 2460 that you
folks seem to have agreed on, but I also believe that workable
solutions can be made that do NOT necessarily depend on SLAs.

As a separate point, however, I would like to raise another
issue.  Let's say that the flow label enables some way to
distinguish a packet flow for special or faster processing.
A malicious node could insert packets with the flow label,
possibly causing the traffic conditioner on the receiving
end to flag an exception and disrupt further traffic to the
destination.  This could happen, right?  This isn't any worse
than a lot of other problems that would come up a long time
before flow-label impersonation, but I wondered whether there
had been discussion about it.

Regards,
Charlie P.

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Jan 2002 12:09:43 -0500

> does allow for future usage.

as I see it, the proposed words let us get Flow Label off our
plates for now, which is good because we don't know what to do
with it anyway.  maybe someday someone wall make a convincing 
case for how to use it.  for now, other things are probably more
worthy of attetion.

Keith

---

From: Richard Carlson <[email-masked]>
Date: Thu, 03 Jan 2002 11:08:16 -0600

I hum for this.

Rich

> > issue of "find quickly").

------------------------------------

Richard A. Carlson				e-mail: [email-masked]
Network Research Section			phone:  (630) 252-7289
Argonne National Laboratory			fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Jan 2002 09:13:37 -0800

> case for how to use it.

and, if we do mbz, they can then write the rfc which changes that

randy

---

From: "James Kempf" <[email-masked]>
Date: Thu, 3 Jan 2002 09:44:16 -0800

I hum as well.
        jak

----- Original Message -----
From: "Richard Carlson" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 03, 2002 9:08 AM
Subject: Re: Where are the WG chairs when we need them? [was Re: Flow
Label]

> > > Now of course, as an operational method, the one above doesn't
scale at
> > all.

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Jan 2002 12:55:21 -0800

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "Randy Bush" <[email-masked]>; "Michael Thomas" <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 03, 2002 9:09 AM
Subject: Re: Flow Label

> case for how to use it.  for now, other things are probably more

For people that build serious (reliable) networks, outside of the research
and academic worlds, those 20 bits will be very useful. They also help to
free up (and use) 16 more bytes in the IPv6 Header. In order to fill out
the 48 byte ATM payloads, it would be good to have the ability to add
up to 8 additional bytes beyond the IPv6 Header. The easiest way to do
that is to use 3 bits of the Protocol Field for the extended length, 1-8 and
an isolated Protocol value for the case where there are 0 extended bytes.
This will yield a 1-24 byte data field in the 48 byte payload. With vPC
wide-pipe encoding, those 24 bytes will on average be able to carry about
18 bytes of data from 6 streams (flows). That can be 3 8-bit voice samples,
which is not a bad sample rate, and key-strokes and telnet chat can ride
in the gaps.

The code should only take a few hours to test....
http://www.dot-biz.com/INFO/Papers/VPC/

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Jan 2002 13:54:56 -0500

hum.

Keith

---

From: "Bill Strahm" <[email-masked]>
Date: Thu, 3 Jan 2002 11:16:50 -0800

I'll hum for this... it is a long time coming...

By the way, where is the RFC describing the monitoring and counting of hums
anyway <G>

Please lets not make something more complex than MPLS here

Bill

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Brian E Carpenter
Sent: Thursday, January 03, 2002 8:27 AM
To: [email-masked]
Subject: Where are the WG chairs when we need them? [was Re: Flow Label]

   Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Jan 2002 14:50:24 -0800

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 03, 2002 8:26 AM
Subject: Where are the WG chairs when we need them? [was Re: Flow Label]

> that can be deployed to support SLAs.

That would be handled by your Multi-Level-Marketing (MLM) sales team ?

http://aso.icann.org/meetings/ac/ac-20012105.html
attendees from 16 countries were present, 55 emerging clients, 5 guests
(Andrew McLaughlin, John Crain, Axel Pawlik, Ray Plzak, Andrea Caro).
The agend was as follows:
a. IPv6 Tutorial
----

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2002 10:40:44 +0100

Hi Charlie,

Theft of service by spoofing the flow label seems to be the same
risk as theft of service by spoofing the DSCP. That is discussed
in RFC 2474 and RFC 2475 and I imagine the considerations
are just about the same.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2002 10:43:24 +0100

> The only draft that we have now is pretty far away from this.

Good point. What we need is a short simple draft to update
2460, independent of draft-rajahalme- .

   Brian

---

From: Alex Conta <[email-masked]>
Date: Fri, 04 Jan 2002 10:06:32 -0500

Brian,

In fact, Jarno, who took vacation around the holidays, promised to work
on a new WG flow label draft immediately on his return. So we will have
that, and everything is going to come out in one package (you are a
co-author).

Alex

---

From: Alain Durand <[email-masked]>
Date: Fri, 04 Jan 2002 15:22:04 -0800

> update to 2460 that Scott and I at least seem to agree

I humm for it. It's time to move on.

    - Alain.