I hum as well.
jak
----- Original Message -----
From: "Richard Carlson" <[EMAIL PROTECTED]>
To: "Brian E Carpenter" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
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:
> >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
> >
> >Robert Elz wrote:
> > >
> > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST)
> > > From: Scott Bradner <[EMAIL PROTECTED]>
> > > Message-ID: <[EMAIL PROTECTED]>
> > >
> > > | 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 PROTECTED]
> >--------------------------------------------------------------------
>
> ------------------------------------
>
> Richard A. Carlson e-mail: [EMAIL PROTECTED]
> Network Research Section phone: (630) 252-7289
> Argonne National Laboratory fax: (630) 252-4021
> 9700 Cass Ave. S.
> Argonne, IL 60439
>
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------
