Subject: Concerns about exported numbers 12/2 12/28/95 11:44:32

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Thu, 28 Dec 95 16:48:42 EST

Reference:  Your note of Thu, 28 Dec 95 11:44:32 PST

Yakov, I think a summary is a good thing, so let me try to take a crack
at it building on what you put together.  It's not that we are that far
apart, but...

0. Supporting any kind of QoS guarantees in the presence of network
elements which do not provide explicit support for such capabilities
is highly problematic.

1. Supporting any QoS guarantees, i.e., Controlled Load, Controlled
Delay, Predictive Delay, or Guaranteed Service, in the presence of
Ethernet switches is highly problematic (even if the 802.1 standard
has been considering the addition of QoS support for some time,
nothing has yet been defined).

2. Supporting QoS guarantees in the presence of Token Ring switches
might be feasible based on the built-in priority support.  However,
even for a Controlled Load service, this will require addition of some
form of call admission (more thoughts are required).

3. Supporting QoS guarantees in the presence of FDDI switches appears
feasible even for Guaranteed Service.
(For Guaranteed Service, setting D = 2 * TTRT (TTRT = Target Token
Rotation Time), C = M (M = Maximum packet size), and relying on the FDDI
call admission and priority capabilities should do the job.  However,
a more detailed investigation is recommended).

4. Supporting QoS guarantees (from Controlled Load to Guaranteed Delay)
in the presence of ATM switches seems feasible.

Would you agree with this summary?

In general, what we seem to be struggling with is the problem of
extending QoS guarantees end-to-end, when we have to deal with *legacy
last hop* devices which do not have support for such things.  It may
be possible to enhance some of them, but the more stringent the service
specification, the harder it is to come up with a feasible enhancement.
Hence, enhancing Ethernet switches to support the Guaranteed Service
is likely to be more difficult than if they only need to support
something such as Controlled (although, I'm not really clear on that).

So we have to provide a trade-off between defining service specs that
can be achieved through relatively small enhancements to existing
devices, and ensuring that we introduce service specs that allow
applications to fully leverage the capabilities that new technology
permits.  You could view Controlled Load and Guaranteed Service as
being sort of on the two ends of that spectrum.  However, I think we
probably need a richer set than that to deal with the kind of
heterogeneity we have.  The Guaranteed Bandwidth spec that was mentioned
before may be one such addition that could help fill some gap.

In general, what you want is very much a set of service specs, so that
you can end-up getting the best service that is feasible on your path,
i.e., the kind of goals described in draft-ietf-intserv-hetero-01.txt.
Defining how to do that together with a set of service specs that
reflects the range of capabilities available from the different
technologies, should go a long way towards allowing you to get the
best possible end-to-end service that is available.  I think this is
clearly preferable to defaulting to the current lowest common
denominator.

Roch

>Let me see if I can summarize the above.
>
>1. Supporting Guaranteed Delay in the presence of Ethernet switches
>is highly problematic
>
>2. Supporting Guaranteed Delay in the presence of Token Ring switches
>is problematic (but more thoughts required)
>
>3. Supporting Guaranteed Delay in the presence of FDDI switches may
>be less problematic than with Ethernet or Token Ring, but further
>investigation is needed
>
>4. Supporting Guaranteed Delay in the presence of ATM switches seems
>feasible.
>
>Would you agree with this summary ?