Subject: Re: Concerns about exported numbers 12/2 1/02/96 14:52:12

From: [email-masked] (Fred Baker)
Date: Wed, 3 Jan 1996 13:08:03 -0800

At 2:01 PM 1/3/96, Curtis Villamizar wrote:
>The second is an issue as long as the IETF still believes in working
>code and not just conjecture that something might or probably will
>work and there is rough consensus to go forward in the face of some
>uncertainty as to whether it will work.  This is all interesting, but
>Personally, I'd like to see this stay draft until there are working
>implementations and some experience.  Standardize now, worry about
>whether it works later is definitely not the IETF way of doing things.

I would have to say that this is the perspective that controlled load comes
from. We have working implementations, and have shown that some very simple
mechanisms with no advertised values at all will provide very good results.
Lee Breslau's simulations (reported in Stockholm by Lixia) seem to say that
the difference between the services show up only in the highest percentiles
- normally, the services are pretty much indistinguishable.

I think that's what we said when we agreed to have the controlled load
service (with no advertisements at all) be the minimal implemntation, and
the others be superset implementations.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Some ideas are so crazy that only an intellectual could believe them...
        George Orwell

---

From: Lee Breslau <[email-masked]>
Date: Wed, 3 Jan 1996 15:20:34 PST

> - normally, the services are pretty much indistinguishable.
Fred,

I don't mean to open up a debate on this subject, since the working
group has already decided on a minimal service with only a single
level.  However, for the benefit of those folks who
may not have been there, I'd like to present a slightly different
interpretation of the results I presented in Stockholm, since you've
referred to them on a couple of occasions.

I am in complete agreement with your statement that the difference between
the services shows up only in the highest percentiles of the delay 
distribution.  But it does not necessarily follow that normally the 
services are pretty much indistinguishable. 

Whether or not the services are distinguishable depends in large part
on how applications use them.  For example, if one believes that some 
adaptive applications will want to set their playback points so they
very rarely miss packets and that they also care about minimizing the 
playback delay, then different levels of service may indeed
provide distinguishable service to the applications.  Similar
average delay does not necessarily imply similar performance as perceived
by the application.  (Of course there are applications for which these
differences will not matter).

Again, I don't mean to start a debate about the number of levels a minimal
service should have.  I only want to point out an alternative interpretation
of the data I presented in Stockholm.

Lee

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Jan 1996 23:38:12 -0500

> the others be superset implementations.

The only problem I have with controlled load is two types of services
want to use it and how you best handle those two types of services
differs radically.  With elastic you allow large queues to form if
bandwidth is exceeded and fair share is exceeded.  Everyone's delay
increases.  WFQ works great and something smarter than tail drop when
queues get too big improves the ability of elastic traffic to get high
utilizations.  For real time traffic you may want allow only small
overloads instead to policy on any larger overload.

I suppose you could specify token bucket parameters for elastic
traffic where burst rate was line rate burst duration was RTT, but I'd
bet some network elements would seriously gag on something like that.
Since you don't know RTT apriori or end to end line rate there is no
way to guess even this.

Do you understand my request for a little bit of additional
information in controlled load.  Perhaps just a bit to indicate
whether traffic is elastic or real time.  If the bit is set, ignore
the burst part of the token bucket and provide buffering to the
aggregate elastic traffic flow appropriate for the delay bandwidth
product of the aggregate elastic flow (link bandwidth minus aggregate
real time flow) and the delay diameter of the network.

Curtis

---

From: "Tim O'Malley" <[email-masked]>
Date: Thu, 11 Jan 1996 14:28:46 -0500

hola.

Curtis Villamizar writes:
 > differs radically.
[...]
 > whether traffic is elastic or real time.

I, too, have this comment on the controlled-load specification.  If we
expect to support applications which care how the network polices their
data, then we should allow those applications to tell the network their
policing preference.  Shouldn't we?

Here is the part of the controlled-load to which I refer:

   FORWARDING BEHAVIOR IN PRESENCE OF NONCONFORMANT TRAFFIC: As
   indicated in Section 7, the controlled-load service does not define
   the QoS behavior delivered to flows with non-conformant arriving
   traffic.  It is permissible either to degrade the service delivered
   to all of the flow's packets equally, or to sort the flow's packets
   into a conformant set and a nonconformant set and deliver different
   levels of service to the two sets.

   In the first case, expected queueing delay and packet loss
   probability will rise for all packets in the flow, but packet
   delivery reordering will, in general, remain at low levels. This
   behavior is preferable for those applications or transport protocols
   which are sensitive to excessive packet reordering. A possible
   example is an unmodified TCP connection, which would see reordering
   as lost packets, triggering duplicate acks and hence excessive
   retransmissions.

   In the second case, some subset of the flow's packets will be
   delivered with low loss and delay, while some other subset will be
   delivered with higher loss and potentially higher delay. The delayed
   packets will appear to the receiver to have been reordered in the
   network, while the non-delayed packets will, on average, arrive in a
   more timely fashion than if all packets were treated equally. This
   might be preferable for applications which are highly time-sensitive,
   such as interactive conferencing tools.

I am envisioning an application which desires the first behavior and
receives the second.  Ouch!

Other than this one point, the controlled-load spec is great.

.....................................................................
.                  .   For every problem, there is one              .
.   happy daze     .   solution which is simple, neat and wrong.    .
.        -tim O    .         -- H.L. Mencken (1880-1956)            .
.....................................................................

---

From: Mark Handley <[email-masked]>
Date: Fri, 12 Jan 1996 11:43:47 +0000

>   such as interactive conferencing tools.

I'm not convinced either of these cases give the service I think some
applications will desire.  I'm thinking in particular about adaptive
applications (such as IVS video) which would like to request a base
service level, and then attempt to adapt above that level when network
conditions permit.

As controlled load is written at the moment, if an application so much
as noses above its specified flow, it can suddenly get greatly
increased delay as some or all of its packets get queued behind a
whole load of TCP packets.  If I run an apaptive playout buffer, I
don't think it makes any difference whether some or all of the packets
get delayed - the effect on the user is that the media stream playout
suffers the larger delay.

For such an adaptive application, I think I would expect each link to
have a class limit for real-time (or controlled load) traffic, and if
I exceed my flow spec but the class stays within its class limit, then
everything's fine.  If the class limit is exceeded, then
non-conforming packets simply get dropped.

I realise this gives potentially higher loss rates than if my traffic
simply gets moved to the best effort class, but it seems that it's
necessary in order to allow adaptive delay-sensitive applications to
be able to exist.  

The problem of course is that this means that a reservation can
produce worse service (in terms of higher packet loss) than best
effort might produce, and this lays us open to denial of service
attacks by someone making a reservation significantly less than a flow
that people are successfully receiving with no reservation.  I can't
think of a good solution to this problem.

Are there any *applications* that actually want to be treated
best-effort (as the current spec states) when the exceed the flow
spec?

Mark