Subject: Multiple transmission requests in cm_request

From: "David G. Andersen" <[email-masked]>
Date: Tue, 31 Oct 2000 23:44:09 -0500 (EST)

A few (last) thoughts about the cm_request issue:

There seem to be two competing issues here:

  a)  Can the congestion controller and scheduler be implemented 
      as efficiently / as well if the API is changed to allow
      multiple packet transmissions to be requested?
      Would mandating this hobble vendors trying to implement
      a working CM?

  b)  Would constraining cm_request to a single packet at a time
      impose unreasonable overhead on performance-sensitive
      clients?

It's fairly obvious that we can continue this discussion well into this
century through lakes of thought experiments about the effects of request
caching and locking, but it seems like this is a terribly obvious place
where some experimentation would settle the issue.  I think that a good
answer to (a) is necessary before any consideration of (b) can be
realistically considered.  My gut feeling is that implementing
(a) will be a non-trivial project.

That said, it seems reasonable and expedient to follow Vern's suggestion
to move on with the interface as-is.  And for now, there are plenty of
opportunities to demonstrate the benefits of a batched cm_reqest -- our
source code is out there for hacking upon, and obviously, the more
independent implementations of the CM, the better!

   -Dave