Marty Schoffstall (email@example.com)
Wed, 09 Sep 87 19:21:31 -0400
My remarks should be interpreted with respect to the DARPA context, where
I have some idea of what TCP and other bangers might do with it (infer
source quench). Yes, is is true that the receiver, not the transmitter,
sees the bit; however, our experience has been that the resources being
starved are usually the buffer pool, which means the bit would probably be
set on either direction at substantially the same frequency. It works
either way, since either or both the transmitter or receiver can crank
back the window size.
Are you then suggesting a "future DOD INTERNET gateway" should implement
this as an option and upon determining "congestion" set the bit for
the receiver and source quench the transmitter?
Still in the DOD context do you feel that a single queued datagram
should set the bit? With our gateways living on the LAN/WAN interface
and the current state of our implementations wouldn't the bit always
end up being set? (And therefore useless to us as a signpost?)
PS: To further the state of the art of Mills'isms: philosophically
if I'm in the swamp with my loaded double barrel shotgun, I'm
probably not going to call for help until I see the THIRD
alligator. DEC seems to be pushing for the sighting of
the first alligator.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT