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