Subject: On services, mechanisms, and naughty bits

From: Scott Huddle <[email-masked]>
Date: Wed, 17 Dec 1997 16:48:19 +0000

What should be a standard, though?  

Services.  Providers are interested in creating useful services 
for their customers, these services may or may not cross provider 
boundaries and, at a service layer, will likely be handled via 
bi-lateral negotations between the providers.  These services
can be created with a (perhaps small) variety of mechanisms.  
It seems unnecessary and unlikely to define a service at the IETF.

Mechanisms.  A single mechanism (like slow-start) may have 
multiple implementations but it's characteristics should be well 
defined and understood (and facilitates useful discussions between
providers for inter-service networking) There have been a number of 
interesting mechanisms that have been discussed in the working group 
and I think all should be standardized (or at least don't care if they
are or are not).  The mechanisms, though, need not be triggered by specific
bit settings.  An MPLS network, for example, could use either 
"Dave's" mechanism or "Van's" mechanism without using bit settings.

Bits.  Whats clear to me is that some providers may want to set
bits to trigger mechanisms to create services.  As we're not sure
what mechanims nor services they will create, it seems unlikely that
we can say standardize "010" as a low-delay service using seperate
queues, and I would argue for a laissez faire approach to bit standards,
and let the "invisible hand" be our guide.

-scott

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Dec 97 15:25 PST

> bi-lateral negotations between the providers.

Some of us (who have yet to be assimilated:-) wonder if some technology
changes may cause a revitalization of public peering points, and that enough
providers may remain that customers may have legitimate expectations of
generic int-serv transiting many providers.

randy

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 17 Dec 1997 18:42:11 -0500

>generic int-serv transiting many providers.

Randy,

Could you expound on the 'generic' part of this? I'd like to hear
your opinions on this...

- paul

---

From: Zheng Wang <[email-masked]>
Date: Wed, 17 Dec 1997 20:41:25 -0500

Scott

I think you raised some very interesting points here which I would
agree. It seems to me that there is a case for multiple service models
that meet different requirements. A VPN pipe (known src/dest and
bandwidth)  and a web-type service (dest unkown) require different 
types of guarantees and traffic isolation. Whether a service model
would be successful also depends on the business aspects (how much
users are willing to pay for what level of guarantees).

Cheers
Zheng

 >and let the "invisible hand" be our guide.

Cheers
Zheng

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 18 Dec 1997 07:14:10 -0500

>users are willing to pay for what level of guarantees).

The more I hear the term "guarantee" used in the discussion of
diffserv, the more I dislike it. For one, I think it is highly
misleading, wholly inaccurate, and unrealistic.

If pressed for a suitable alternative, I would have chosen
"assurance".

- paul

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Thu, 18 Dec 1997 08:43:33 -0500 (EST)

In principle, I would love to agree with these observations. 

> It seems unnecessary and unlikely to define a service at the IETF.

However, I believe there is a flow in this argument. 
How can the service provider engineer a service in its 
own network ? I consider it as receipe for failure if 
providers restrict themselves to single vendor solutions !!
If two or more types of equipment are used, and they support a 
slightly different service, how can a service providers network
 be engineered? 

I think it is exactly this reason that makes necessary to specify
as much as possible, without of course restricting vendors from
defining their one queue management or scheduling mechanisms. The
semantics of a minimum service must be very well defined, and vendors
can differentiate in the accurate/competitive implementation of 
the service or extensions of the service models.

Regards,

- Dimitri

---

From: [email-masked] (Pawan Goyal)
Date: Thu, 18 Dec 1997 10:09:56 -0600 (CST)

> If pressed for a suitable alternative, I would have chosen

Could you please clarify the semantic difference between
"guarantee" and "assurance".

Pawan

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 18 Dec 1997 11:40:28 -0500

>"guarantee" and "assurance".

Guarantee implies an absolute.

Assurance implies a probability.

- paul

---

From: Scott Huddle <[email-masked]>
Date: Thu, 18 Dec 1997 14:29:37 +0000

Dimitri,

In today's Internet there exists just one service "best effort",
at which some providers are better at providing tha others to
such a degree that marketing types are relegated to trumpeting
a service description of "we suck less" ;)  Different providers
can use different mechanisms today to provide that same service 
(tail drop, RED, fair-queing, etc) and yet the IETF doesn't
need to define the service that is created with those mechanisms.
Additionally, providers glue together networky bits that provide
the mechanisms they deem appropriate to provide the less sucky
service, these interoperate or not based on understanding and 
implementation of the mechanisms that they select.

Similarly, I don't think that we need the IETF to standardize what
the "new/better/with retsin" services are to be, but instead focus
on mechanism standards.  In terms of interoperability, I think
your issue relates around which bit patterns match which mechanisms
and or services, and I don't think that this is likely and or possible.

As a provider, I want the ability to invoke an arbitrary mechanism
to an arbitrary bit pattern, and to remap those bit patterns on
entry (and perhaps on exit).  This provides at least one minimal
set of flexibility required to build a service.  
 
-scott