Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!cit-vax!ucla-cs!zen!ucbvax!NIC.NYSER.NET!schoff
From: schoff@NIC.NYSER.NET ("Marty Schoffstall")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ISO8473 vs. IP
Message-ID: <8709092321.AA04042@nic.nyser.net>
Date: Wed, 9-Sep-87 19:47:58 EDT
Article-I.D.: nic.8709092321.AA04042
Posted: Wed Sep  9 19:47:58 1987
Date-Received: Fri, 11-Sep-87 07:19:09 EDT
References: <8709091349.aa17070@Huey.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26


    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?)

Marty

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.