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

--------------------------------------------------------------------
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

>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).

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: 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: 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.

   Brian

Robert Elz wrote:
> 
>     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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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: 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: Keith Moore <[email-masked]>
Date: Thu, 03 Jan 2002 12:09:43 -0500

> 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.

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: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Jan 2002 17:18:58 +0100

Randy,

  Brian

---

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

kre

---

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: "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]

> I hum for this.
>
> Rich
>
> At 05:26 PM 1/3/02 +0100, Brian E Carpenter wrote:
> > > Now of course, as an operational method, the one above doesn't
scale at
> > all.
> ------------------------------------
>
> 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: Keith Moore <[email-masked]>
Date: Thu, 03 Jan 2002 13:54:56 -0500

hum.

Keith

---

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: 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.

---

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: 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