Minutes of the Future Directions for Differential Services BOF (FDDIFS) Working Group
Reported by: Allison Mankin
II. Brief presentations on needs for differential servicesa. Randy Bush, Veriob. Bob Moskowitz, Chryslerc. Steve Polinsky, Goldman-Sachs
Principal goal is to understand what differentiated services on the Internet customers want to buy, and providers want to sell. Non-goal today: technical design or criticisms of specific solutions. Also, non-goal today to relate services to business models, and it is important to take care on this, as an upcoming internet draft, which the IAB/IESG prepared, and had considered by ISOC lawyers, and now by the POISSON Working Group, will make clear. The initial speakers were lined up to speak to the principal goal.
a. Randy Bush, Verio, [no slides]:
Two comments -- a friend from a prominent ISP left the room because his lawyers won't let him talk in public about what customers want. Randy can talk, being from bottom-feeding, scum-sucking ISP. One word: CBR. A single 10 Mbit line costs less than ten 1 Mbit lines (physics). If an ISP can sell portions as Constant Bit Rate services, it will make money, that's it.
In this talk, representing AIAG (Automotive Industry ANX Group). Thousands of suppliers involved, as well as the players in AIAG itself. Trucking industry invented EDI 14 years ago, automotive took it up 13 years ago. 5M transaction sets/month. Use 9600 baud lines now, want to go to 2 MB. Shipping notices are near-real-time - three minutes to turn around, of which one minute is for back-end processing. Contractual requirement to make it get through in time. Chrysler has 2000 trading partners, 200 of them high volume. Network must perform. For real-time requirements, CAD design teams are starting to move to virtual reality design rooms, which work well enough over ISDN, but need all of its capabilities. Field testing -- real-time analysis of instrumented cars to steer the testing in remote sites (heat, cold). Robotic diagnostics -- suppliers must be able to work directly with the robotics over the net when there is an urgent problem. (If a car assembly line is shut down for 20 minutes, the shift is sent home.) Today companies are running separate links to each robotics supplier, big cost saving to put on general net if it could deliver the service. Future growth: dealerships, engineering control of vehicle diagnostics over the net. This will be a very competitive area and is significant (the auto industry is 1/6 of US economy/US jobs). Security must be multi-company mesh, IPSEC is planned.
Q: Is it fair to say the principal requirement is predictability?
A: As for mainframes, need a known worst latency, ok to be consistently close to this. ASNs are probably typical in their timing, not extremely tight, small size of transfer. Important additional point: MULTI-PROVIDER!
c. Steve Polinsky, Goldman Sachs:
Profitable network applications, such as Research Express. If it's not there when you want it, customers lose. Can't fully quantify needs, but clients will have different amounts of urgency, and may be anywhere. Sales forces all over the world need the quality of the net. Engineering solutions to achieve this:
1. Use the Internet as is -- slow, unreliable, insecure.
2. 3rd party global VPNs -- expensive, complex.
3. Build out corporate net toward clients, from existing POPs -- expensive, unmanageable.
4. Connect corporate net to many ISPs in many places -- expensive, complex
Want: Better quality Internet service. Will pay for it. Don't want to worry about crossing boundaries. Avoid unmanageable private infrastructure, but need high bandwidth between own data centers.
Q: You can't quantify your response time requirements?A: No. We just want comfort and quickness. Client says, "it's just a little slow for me, so I don't use it," G-S winds up installing a T1, the revenue from the client can be a million or so.
d. Keith Johnson, FEDEX: 1700 domestic locations, 300(?) outside US, need "same quality of service for all." Internal communications can be controlled, or fixed by adding bandwidth, so why do differential services internally? To manage and anticipate performance problems - this is worth money. 100,000 automation devices are connected via a 3rd party global VPN to offer local comms costs for the users everywhere.
About quantification of requirements -- customer satisfaction was greatly improved by letting the modem training be heard by customers -- they knew the communication was starting. Be careful when quantifying "a little slow."Policy -- Avoid exchange points, use multiple providers, and have FEDEX on same provider as customer (to simplify problem resolution). If secure differential services are offered, FEDEX will use them.
e. Terry Davis, Boeing: Boeing has one primary ISP now, but plants want connection to ISPs in their area to support work-at-home. Closed network inside Boeing, routing and addressing transition is very hard. Will be moving large MVS complex from SNA to IP. Service level requirements on that to maintain existing SNA functionality. Moving towards real-time use of global resources such as wind-tunnels all over the world. Sharing CAD systems with customers and vendors, major requirement is consistency. Need to get engineers video-conferencing with each other throughout the world. Have large cluster of ~2500 systems sharing a common image (1.5 Gbytes). Need reliable multicast for download-- a constant bit rate service, used at rate of slowest link. If links are changing or can't tell what their rate is, the reliable multicast protocol solution they have are infeasible.
III. Open Mike Discussion (Speakers not identified and some comments combined)
Customers complain a lot and want QOS badly on internal networks, not just the Internet. We need to address that. The number one requirement is to keep the customer’s service level agreements -- 1. end-end response time (keystrokes) 2. Human factors. Web to do 3270. 3. IPSEC has a nasty side effect that it conceals the port numbers needed for use in WFQ.
Most Common complaint is keystroke response, but numbers 2 and 3 are data center backups at night (want reservation) and bulk distribution of data, where a missed window means that the entire distribution is backed out. Turns out the servers are bottlenecked, so reservation isn't critical here.
ISPs as technology customers want to be equipped for providing differential services, differentiating what content is accessible and how fast. Tiering services on shared 25Mbs. Not constant bit rate. Parameters include minimum guaranteed bandwidth, frame-relay type CIR. Thousands of subscribers in home. On demand, go to more service. Purely residential or work-from-home.
Q: What granularity of choice of high quality?
Basic guarantee is for the whole cable modem, ability to increase across all IP services at a given time. Want to be able to add 64kbps streams at certain times for second phone line only during the day (e.g., work from home).
Q: What did you want from what intserv and rsvp? Is there any more specificity from them?
An individual requirement is local CBR high bandwidth, long distance pay-per-use CBR.
Compuserve is 50% network services and 50% information provider. Need help in support of connecting people to proprietary data. Know how to bill but we have an authentication problem. We need to be able to authenticate who we're connecting for either micro or macro payments. We don't have other particularly differentiated services.
Q: Are you arguing that an authenticated service is a form of differentiated one? Yes.
Lessons can be learned from frame relay. FR customers have wanted FR to provide differentiated services and be able to offer them common measurements (frames dropped over time, etc.) so they can shop around.
Q: Is multicasting a differential service? Looking for it to be a solution.
Differential service requirements can be application-based, time-based, or size-based. For example, software distribution problem: get 1 Mbyte sent to all locations within two hours. Get 13 Mbytes to 1000's of machines in bounded time (e.g., overnight).
One issue that triggered this BOF is what granularity of services -- individual transactions, inside providers, multi providers. Still encourage comments on this.
Q: Question about purpose of this discussion. What would the Working Group output of this be?
A: (Scott Bradner, imminent Area Director): No Working Group planned. Probe where we go in the future from/beyond the RSVP last call.
A: (BOF chair): Note that there will be an IRTF research group on Reliable Multicast.
It's not enough to get control of differential services and accounting into clients and servers. The infrastructure has to get fixed too, e.g., route flaps. One corporate network every week configures 250,000 resources to deliver desired QOS. They aggregate users into classes in order to make it feasible.
Main need as we migrate to ISP services is scheduling multiple needs on one circuit, RSVP only partly handles this.
Multiple trading partners have to negotiate and commit resources that meet needs. Don't care whether solution is gigabit pipes in a terabit net, or carefully crafted to match needs, but must be multi-ISP. Communication. If you toss out dollars, you'll get something, not necessarily what you want...
Q: What role can the IETF play? We're debating this, but at least one vendor and ISP claim to have it already. Let the market forces do their job.
A: If company A is using TOS bits and company B uses ports, we want to help to have them interoperate. Can we rest just because RSVP and intserv are published?
Vendor or provider view is, "I can't say why my customers want it, but they do." IETF can provide multi-provider, multi-service view. RSVP Applicability Statement makes clear we also contribute to making large scales of solution.
1. Granularity of time is what decides if RSVP or something else is appropriate.
2. There aren't a lot of technologies here. The hard thing to understand is not the flow of packets but the flow of money and the money doesn't follow the packets. If we're going to do something multi-provider etc., it's not going to be about the packets, but the flow of money, and not sure if IETF can or can't do it.
Q: Why we couldn't do it? Too stupid or not allowed?
A: Not because IETF is too stupid, but how can a technical body that can walk on the 'World War I negotiated truces, trench lines' of the ISP’s agreements which are delicately balanced to avoid settlements.
By defining mechanisms, the IETF inadvertently makes a framework and being more explicit about framework would be good. Some ISPs would like to do end-end QOS. Shortest exit may not be acceptable in future because of absolving responsibility by primary ISP as soon as possible.
We don't have standards track accounting protocol for within providers, let alone between providers. Needed for billing but also auditing.
So QOS auditing is a prerequisite for deploying differential services?
Interim Summary (Scott Bradner, Allison Mankin)
Most of what we heard so far is that the Internet should work better. It seems QOS mechanisms haven't 'cooled down yet,' and we need to try them. Maybe we're just hearing that people don't want an overspecified service that is sophisticated.
Current RSVP specs don't include aggregation method and therefore the Applicability Statement doesn't make recommendations that RSVP be used over aggregated traffic streams for differentiated service.
We are hearing that Internet is lousy now, fix it in the future. ISPs have large content providers who don't ask the infrastructure to treat their traffic differentially, but if they're sophisticated they use Treno. Do they not ask for intserv and rsvp because they don't perceive it or because there isn't a need?
There is a wide range of services needed, from on-demand to broad. Heard from the customers that they wanted something that was provided by something like CBQ, and that they're looking for managed bandwidth service, managed over longer periods. Available bandwidth above some floor is how I define it. Sufficiently important and perhaps it should be addressed.
Cost versus QOS tradeoffs are common, e.g., credit card swipers using dialup, private, or X.25. The criteria don't come to us very much, we don't have a lot of handle on generalizing the customer base who does public versus private decision making on the largest scale.
Cornell is about to go to a differentiated service on campus. Business problem: can we give the guarantee not over average but when you do a specific transaction? Want to alleviate the risk of failure. Business decision about the risk, not the technology. University has one need, FEDEX others, etc.
When throwing bandwidth at the problem, traffic expands to fill bandwidth.
There should be some follow-on to this BOF: If differentiated service is going to exist in Internet, an old IETF principle says it should be in one form, not many.
We see services we need from some individual ISPs -- 250 ms maximum latency anywhere in US advertised by some ISP or collection of ISPs.
Reservation of bandwidth -- we want to be able to reserve ahead of time as with the multicast of WWW6/IETF38 etc.In European ATM we've used signaling to get VCs by telefax.
Regarding what granularity we want for services: all granularities are wrong, and all granularities are right. We need the full range.
Imagine a model of a completely differentiated service arrangement. Open a TCP connection, pick a bandwidth, cost of connection will be more if bandwidth more. What would the business community do with this? Would they learn that they didn't need the top qualities? (This is a gedanken experiment, not a practical proposal.)
We mainly heard today about small transactions from many locations. So bandwidth of a single connection is not a predominant concern.
We're hearing that ISPs want to offer a few, say five, grades of service. Key thing is differential pricing. Once you start charging extra, you must be able to prove that the customer is getting what they paid for. Service level agreements.
FEDEX provides a differential service over 32-cent postage. We only get our money if we can prove that we did what you paid for. What was heard today: consistent, expectable service. McDonalds model! Your expectations are met. It's not clear how many levels of service the market really wants.
Continued availability and schedulable: if I can get it today for $100 can I get it next week? Can I assure ahead of time that I can have it next week?
IETF is not really good at choosing between several fundamentally different approaches. You let the marketplace flesh out a variety.
An interesting taxonomy of differentiated services is derivable from our discussions today.
1. McDonalds -- extremely high value placed on predictability. BOF chair was not sure if the IETF could do anything here. [But minutes-taker would think that perhaps it could...]
2. USPS/FEDEX -- two services, one cheap and one expensive -- But for one carrier to offer the expensive type on its own is unrealistic, and coordination is hard. BOF chair summarized that IETF may want to flesh out how to do this and let the marketplace decide how/whether to use it. Important points: the small number (two or not many) of services and the intercarrier nature.
3. Lots of services -- finely differentiated [worth saying that the transcript above shows that few in the room gave any sense that this was on their minds].
The Chair thanked everybody, and we left the room ... [on to great things].