I'd like to look at the set of rate-based papers you are collecting
before I express an opinion on your last question ;-)
tom
-------
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by emigrant.cs.washington.edu (8.8.5+CS/7.2ws+) with ESMTP id MAA19659 for <tom@emigrant.cs.washington.edu>; Thu, 11 Jun 1998 12:20:54 -0700 (PDT)
Received: from tesuji.cs.washington.edu (tesuji.cs.washington.edu [128.95.2.82]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id MAA05809 for <syn@cs.washington.edu>; Thu, 11 Jun 1998 12:20:41 -0700
Received: (from hoffman@localhost)
by tesuji.cs.washington.edu (8.8.7/8.8.7) id MAA07709;
Thu, 11 Jun 1998 12:20:37 -0700 (PDT)
(envelope-from hoffman)
Date: Thu, 11 Jun 1998 12:20:37 -0700 (PDT)
Message-Id: <199806111920.MAA07709@tesuji.cs.washington.edu>
From: Eric Hoffman <hoffman@cs.washington.edu>
To: syn@cs.washington.edu
Subject: re: random responses
Status: R
The history was reversed. Digital AN2's per-flow credit scheme
was designed in late 90 before ATM had any congestion control or
even circuit setup standard (these appeared in 93 or so); the original
AN2 had 128 byte cells, a link speed that wasn't a 4^k multiple of 56Kbps,
etc.
sorry, I thought you had mentioned that the AN1 had been rate-based.
one of the primary reasons given for not selecting credits was the
associated switch costs. however, it turned out that the end-system
rate implementations had different behaviours, and no one got around
to implementing reliably correct ABR machinery on the switch-side
(which was hardly cheap either)
[as a side node I once spent an entire day trying to track down a
strange error with our software only to discover that the dec
gigaswitch-atm was mournfully sending out credits on a vc we
had thought we could use]
let me ask a different question, do you think there is likely to be
large differences in areas such a stability and performance between
rate and buffer-reservation based credits?