Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/97apr/fddifs-minutes-97apr.txt

Text File | 1997-05-29 | 17KB | 400 lines

Editor's Note:  These minutes have not been edited.



Future Directions for Differential Services BOF (fddifs)

Monday, April 7, 1997 at 0930-1130
==================================

Chair: Brian Carpenter
Minutes: Allison Mankin
Attendees: approximately 130

Agenda: Introduction
    Brief presentations on needs for differential services
              Randy Bush, Verio
              Bob Moskowitz, Chrysler
              Steve Polinsky, Goldman-Sachs
              Keith Johnson, Fedex
              Terry Davis, Boeing
    Open discussion
    Summary

------------
Chair's Introduction

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 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 WG, will make clear.
The initial speakers were lined up to
speak to the principal goal.

------------
Brief Presentations

Randy Bush, Verio, [no slides]:

Two comments -- a friend from a
prominent ISP just 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.


Bob Moskowitz, Chrysler:

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 - 3 mins to turn around, of which 1 min is for back-end
processing.  Contractual requirement to make it get through in the
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 mins, 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 competitiv
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!

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, 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.

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, to have
FEDEX on same provider as customer (to simplify problem resolution).

If secure differential services are offered, FEDEX will use them.

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.

------------

Open Mike Discussion (speakers not identified and some comments
combined):

Customers complain a lot and want QOS badly on internal networks not
just the Intrnet.  We need to address that.  Number one requirement is
to keep the customers 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.

Commonest complaints are 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 bottleneck, 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? A: Basic guarantee is
for the whole cable modem, ability to increase across all your 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 (work from
home, e.g.).

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.  Kow 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?

A: yes.

Lessons can be learned from frame relay. FR customers have wanted FR to
provide diff serv and be able to offer them common measurements (frames
dropped over time, etc.) so they can shop around.

Q: is multicasting a differential service?  A: Looking for it to be a
solution.

Differential service requirements can be application-based,
time-based, or size-based. Example:  software distribution problem:
get 1 Mbyte sent to all locations within 2 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 WG output
of this be?

A: (Scott Bradner, imminent Area Director):  no WG 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
1 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? A: 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
multiprovider 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, not allowed?

A: not because IETF is too stupid, but how can a technical body can
walk on the 'World War I negotiated truces, trench lines'  of the ISPs
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 was that the Internet should work better.  It seems QOS
 mechanisms haven't 'cooled down yet', we need to try them.  Maybe we're
 just hearing that people don't want an overspecified service that is
 sophisticated.

-------------
More Open Mike Discussion

Current RSVP specs and 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 perhaps it should be
addressed.

Cost v. 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-vs-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.

Re whether 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 signalling to get VCs by telefax.

Re 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 connecion, 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 many
locations.  So bandwidth of a single connection is not predominant
concern.

We're hearing that ISPs want to offer a few, say 5, 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 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.

------------
Chair's Summary

An interesting taxonomy of differentiated services was derivable from
our discussions today.

1. McDonalds -- extremely high value place 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 -- 2 services -- 1 cheap and 1 expensive --
   But for 1 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 (2 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]



------- End of Forwarded Message