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