Subject: comments on guaranteed delay service

From: [email-masked] (John Krawczyk)
Date: Wed, 17 Jan 96 19:01:54 EST

Sorry for taking so long to do this.  Most of what I have to say has
been said in one form or another, so this is mostly reinforcement.

First of all, we need the appendix with the RSVP ADSPEC, FLOWSPEC,
and SENDER_TSPEC formats.

   The parameter C is the data backlog resulting from the vagaries of
   how a specific implementation deviates from a strict bit-by-bit
   service. So, for instance, for packetized weighted fair queueing, C
   is set to M.

(A question I've had for quite a while).  Does this also account for
the serialization delay on the outgoing link?  If not, where does this
figure in?

I think that the "Guidelines" section should discuss in a little more
detail the difficulties of specifying an accurate C and D.  If the
connection between two nodes is a full-duplex point-to-point link,
things are pretty simple.  Unfortunately, there exist today a lot of
subnets comprised of frame switching equipment (frame relay, ethernet
switches, etc.) and ATM is becoming an issue (I actually consider ATM
an easier case).  In these cases, the router sometimes doesn't have a
clue about the additional serialization and fixed delays that will
occur.  The approach suggested for shared ethernet could be used:

   the queueing schemes work correctly).  For an Ethernet, it might
   represent the worst case delay if the maximum number of collisions is
   experienced.

but how do you come up with the right numbers for a frame-switched
network?  And if you use these numbers, is anyone going to be
satisified with the obtainable delays?  How big will R have to be to
realize something useful?

Of course, what we really need is for the switches to participate in
the service model, but there already is a lot of stuff deployed that
doesn't, and never will, participate.

I guess I'm pessimistic about who will actually use guaranteed.  Those
really needing it will have to engineer their networks accordingly.

-jj