Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!MITRE.ARPA!mckee
From: mckee@MITRE.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Analyzing Acknowledgement Strategies
Message-ID: <8701161826.AA07043@mitre.ARPA>
Date: Fri, 16-Jan-87 14:10:14 EST
Article-I.D.: mitre.8701161826.AA07043
Posted: Fri Jan 16 14:10:14 1987
Date-Received: Sat, 17-Jan-87 01:37:01 EST
References: <8701151850.AA18157@lbl-csam.arpa>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The MITRE Corp., Washington, D.C.
Lines: 26
Approved: tcp-ip@sri-nic.arpa

>ps- perhaps we should take this discussion off line?  I've been
>   filling up peoples' mailboxes lately and I get the impression
>   that there are only two or three of us interested in this topic.

I expect/hope many people are interested.  The current MIL-STD 1777
and 1778 are incomplete; they need a section called Implementation
Guidelines.  The work that you, Mills, Nagle, Partridge, et al are doing
will be the basis of that section.  At any rate, while I can contribute
little more than intense interest, please include me in your
discussions.

I would particularly like to hear from John Nagle on:

>A quick look at some trace data suggested that there was a problem
>when you resumed normal behavior after a retransmit.  Since you'll
>always be sending into an empty window at this point, 4.3 will blast
>out 8 back-to-back packets.  A couple of packets near the end of this
>blast are almost certain to be dropped so you'll end up in retransmit
>state 2 RTT after the previous recovery.

I would offer the following comment: Packets are lost by Gateways, not
PSNs.  The PSNs can protect themselves against an input overload from
subscribers; Gateways can only whimper Source Quench.  Accordingly, we
should thump on the egp-people people to "do something."

Regards - Craig