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 PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Brian E Carpenter Sent: Thursday, January 03, 2002 8:27 AM To: [EMAIL PROTECTED] Subject: Where are the WG chairs when we need them? [was Re: Flow Label] 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
