Subject: Stockholm Minutes of INT SERV

From: Craig Partridge <[email-masked]>
Date: Fri, 04 Aug 95 11:33:20 -0700

MINUTES OF THE INTEGRATED SERVICES WG MEETING
		    Stockholm IETF

John Wroclawski gave a brief overview of the integrated services
work and presented the template document.  There were several comments
on the template:

    * Bob Braden suggested that "resulting service" should be moved
    earlier in the templates (rather than having to read to the end
    of the documents to find out what all the text is actually going
    to result in)

    * There was some discussion about where OPWA fits in - is it part of
    the service model (Bob B.'s opinion), part of the reservation
    model (several int-serv people's opinion), or neither? In any case,
    where does it get specified, if at all?

    * There needs to be a piece of text somewhere describing the token bucket in
    precise terms; at present we only seem to have non-existent
    references.

    * On the subject of data formats, there was some debate about why we
    need both an abstract definition and a specific representation. The
    answer was so that those protocols that wanted to use some other
    representation could use the abstract definition to figure out what to
    do.

    * Questions were raised about merging composition functions at
    merge points (no resolutions -- just that the documents current
    only think in terms of single flows end-to-end)

Craig Partridge presented the guaranteed service document (observing
that despite his travels, he believed he was currently up to date on
the e-mail).  Most of the comments were written down on the slides
as explicit modifications to the spec (and thus will be reflected in
the revised draft).  Some key points that were raised:

    * the PDU size used by the flow matters -- one has to compute
    link level overheads and the frequency with which link level
    headers occur is based on PDU size.  After discussions about
    whether to try complex characterizations of the PDU size range,
    we decided to use the simple approach -- just specify the minimum
    size.  Walter Milliken notes that some equipment is packet rate
    limited and by only specifying the min size we'll cause them to over
    estimate the max packet rate -- we decided to live with that
    problem.

    * the document currently only talks about queueing delay and does not
    describe how propogation delay through links (which may be ATM subnets
    and thus have to be represented as service elements) is to be accounted
    for.  This is to be fixed.

    * the range of rates was wrong (and wrapped up with the notion of
    policing in bizarre ways).  So the range is to be changed to allow
    for as little as 1 byte per second and the policing text is to be
    improved.

    * we discussed the possibility of including a priority in the TSpec
    but the group wasn't sure that this bought us any advantages and
    it did have clear disadvantages (such as forcing us to support
    priorities in any queueing scheme we put into any router).

    * there was a discussion of what floating point format to use
    in the TSpec and the agreement was to use IEEE representation (and
    stop trying to develop our own).

Lee Breslau gave a short talk on predictive service, showing graphs from
experiments which showed predictive service generally maintained delay
within bounds quite well, and had rare but extended excursions above
the delay bound.

After lunch, John W. presented the controlled delay draft.  Again
key comments are summarized:

    * the draft was unclear about the loss model.  Does controlled delay
    deliver all packets, but some late?  Is low loss both queue loss and
    being late?  Is loss advertised?

    * the issue of substution of controlled delay with guaranteed service
    raises the question issue of guaranteed having added the packet size
    to the TSpec. Answer, nice to match guaranteed and controlled delay.

    * There was a discussion about exported information.  We're exporting
    9 numbers, measured over intervals as short as a second.  It was clear
    that we'd like some detailed information about short term behavior
    but that we're also collecting the wrong information (namely worst
    case delay, when what we want is closer to the delay within which
    99% of all packets arrive).

Lixia Zhang presented an alternative controlled delay service suggested by
her and Sally Floyd.  The differences between it and the proposed service
was that that new service would have only one level of queueing and no
advertising.  The room generally preferred having multiple levels of
queueing available, even if some implementations only use one level of
queue (which is permitted by the spec).

Bruce Davie spoke on policing.  He made several important points.
     
    * Policing needs to be done at both source merge points and at `split
    points' (places where the multicast tree splits) when the reservation
    downstream from the split point is less than at the split point.

    * Policing by dropping has the potential to disrupt the service of
    receivers who may have been receiving adequate service prior to the
    installation of a reservation. This suggests that alternate approaches
    should be sought. These include marking non-conforming packets,
    reshaping to restore conformance, and relegating non-conforming
    packets back to best effort. While reshaping in general adds delay,
    Craig pointed out that for guaranteed, one can show that the delay
    added is still within promised delay, and it was decided to require
    reshaping for guaranteed. 

    * Policing at points other than the network edges needs to be done
    carefully, since traffic may become more bursty as it passes through
    network elements. Thus, using a token bucket filter that was specified
    at the edge is not an acceptable way to do policing. 

    * Since the burstiness of a flow changes as it traverses the netowrk
    may change but its average rate does not, it might be desirable to
    police based on the token bucket at the edges and to police on rate
    only at merge and split points. Bruce is still working on the math for
    this idea.

    * More work is needed on the marking and relegation to best effort
    approaches.

John W.  spoke about the proposed flow spec.  General agreement that
it looked good.  On the only major issues, the vote was for self-parsing
formats and for 0 based length.

There was then some brief concluding discussion about where to go next.

    * It was felt desirable to progress controlled delay and guaranteed
    at the same time.

    * Guaranteed (once changes made during the meeting where applied)
    seemed ready to go to Proposed Standard, with a brief comment period
    on the list to ensure that changes were made correctly.

    * Controlled Delay is in slightly less ready state, particularly
    related to the issues of loss vs. late delivery vs. discard and
    advertising parameters.  The plan was to send out a revised version
    to the list soon and if there prove to be lingering issues, to call
    an interim WG meeting (probably at SIGCOMM).

    * The group felt the flow spec document was sufficient simple and
    close to the right form that it too could go on the standards track
    after a comment period on the WG list.

---

From: [email-masked] (John Krawczyk)
Date: Mon, 7 Aug 95 17:07:14 EDT

Quick question: are we going to support multiple precisions or pick
one (like 32-bit single precision)?

-jj

---

From: Craig Partridge <[email-masked]>
Date: Mon, 07 Aug 95 14:29:37 -0700

We should pick one.

Craig

---

From: [email-masked] (John Krawczyk)
Date: Mon, 7 Aug 95 18:32:45 EDT

On Mon,  7 August, Craig Partridge ([email-masked]) wrote:

   We should pick one.
   
   Craig

OK.  I'm no expert on this stuff, so I'll just regurgitate what I've
looked up:

The single precision format provides a 23-bit fraction (plus one is
always implied) and an exponent between -126 and 127, inclusive (8
bits are used; actual values are 1 through 254, with a bias of 127).
For example, an exponent of .5 and an exponent of 20 yields 1.5 * 2^20
(1048576) = 1572864.  I think this gives us plenty of breathing room,
no?  Is anyone going to ask for fractions of a bit per second?  :^)

[someone please correct me if I've misinterpreted this]

A few things we should add to the use of the format in the int-serv
specs:

1) For quantities that do not make sense as negative numbers, the sign
bit must always be zero. (just about everything)

2) Legitimate ranges should be specified for each parameter
represented as a floating point number.  E.g., 1 bit per second is the
minimum acceptable value for bandwidth, or something more reasonable.
(actually, #1 is just a special case of this).

3) The exponent field has two special values: 0 and 255.  The only
uses I can see for these is to designate zero (zero for both exponent
and fraction) and maybe infinity (255 exponent, zero fraction).  For
each parameter represented as a floating point number, we should say
whether or not these values are legal (and what they mean).

-jj

---

From: Craig Partridge <[email-masked]>
Date: Mon, 07 Aug 95 16:11:13 -0700

jj:

    I would have assumed zero was standardized???

Craig

---

From: John Wroclawski <[email-masked]>
Date: Mon, 7 Aug 1995 20:09:35 -0400

From: Craig Partridge <[email-masked]>

   We should pick one.

I believe what we actually said in Stockholm was "IEEE 32b single
precision format"...

---

From: John Wroclawski <[email-masked]>
Date: Mon, 7 Aug 1995 20:34:14 -0400

From: [email-masked] (John Krawczyk)

jj,

The template document already requires you to give an abstract
range/precision specification for data quantities, as well as giving a
preferred specific format if you want to - so this is already covered?

All of these have defined meanings. e(xponent)=f(raction)=0 means zero
(note that there both positive and negative zeros...). e=255, f=0 are
the positive and negative infinities. e=255, f!= 0 are the NaN's (not
a number). An (overly?) clever person might choose to use the
signalling NaN's to represent special conditions such as "don't
care", but this raises some compatability issues. If we did allow that
we should start assigning global meanings to specific NaN bitpatterns,
I think.

			-john

---

From: [email-masked] (John Krawczyk)
Date: Tue, 8 Aug 95 08:57:10 EDT

jj:

   Craig

Lack of clarity on my part, given that I was quickly composing the
message while really trying to go home :(...  The examples I gave
above _are_ standard, and I was suggesting that these were the only
ones we'd probably be interested in.

Anyway, John W.'s subsequent message (thanks John) clarified the
"standard" representation for zero, as well as the other "more
interesting" uses of 0 and 255 exponents.

-jj