Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!G.BBN.COM!CLYNN
From: CLYNN@G.BBN.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Interlan drops a byte?
Message-ID: <[G.BBN.COM]25-Aug-88.11:59:42.CLYNN>
Date: 25 Aug 88 15:59:00 GMT
References: <8808241123.AA18269@fnord.umiacs.UMD.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 20

Steve,
	It looks like another instance of the "have to retransmit a
FIN, so better subtract one from the sequence #" bug. Note that the
response (maybe to pktnum 2483, but possibly to an earlier packet
since the timestamps on 2483 and 2484 are identical) in pktnum 2484
was to ack 1d52f72. Thus the receiver has already received the data
being retransmitted in pktnums 2485, 2487 and 2489.
    [Clearly useless retransmissions -- maybe (the timestamps are all
    very close) an instance of the "retransmit all unacked data on a
    retransmission timeout" algorithm, or (the timestamps are not
    exactly equal) a "retransmit on ack before updating/processing
    send-left & processing the retransmit queue" design deficiency].
It would have been nice if the trace began earlier, say on the first
transmission of the packet containing sequence number 1d53100; was
a FIN sent at the "same" time?
    [Note [fnord sends its fin, with seq  # 108d4e02] you mean 108d4e01.
    Also, notice that in pktnum  2492, a FIN is being  (re)transmitted at
    a different sequence number, 1d53102, than it was in pktnum 2489,
    1d53101 = 1d52f71+190.]

Charlie