Re: [tcpm] Handling of FIN in the reassembly queue

David Borman <dab@weston.borman.com> Fri, 22 February 2008 21:28 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9881328C402; Fri, 22 Feb 2008 13:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.039
X-Spam-Level:
X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbdE4QqCdavj; Fri, 22 Feb 2008 13:28:41 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FEC28C25A; Fri, 22 Feb 2008 13:28:41 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF0D3A6BCE for <tcpm@core3.amsl.com>; Fri, 22 Feb 2008 13:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G02mkppRa-4C for <tcpm@core3.amsl.com>; Fri, 22 Feb 2008 13:28:39 -0800 (PST)
Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 7825F3A69D7 for <tcpm@ietf.org>; Fri, 22 Feb 2008 13:28:37 -0800 (PST)
Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id m1MLSF5G026529; Fri, 22 Feb 2008 15:28:17 -0600 (CST)
Message-Id: <A2C7B5B5-E8E3-4A39-8D75-5FDD0BE86692@weston.borman.com>
From: David Borman <dab@weston.borman.com>
To: Anantha Ramaiah (ananth) <ananth@cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 22 Feb 2008 15:28:14 -0600
References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com>
X-Mailer: Apple Mail (2.919.2)
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Handling of FIN in the reassembly queue
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Feb 22, 2008, at 1:38 PM, Anantha Ramaiah (ananth) wrote:

> David,
>   Pl see inline..
>
>> For any TCP connection, in each direction there can be only
>> one FIN, it will never move, and there will never be any
>> valid data transmitted after the FIN.  So, if you get into
>> this situation, you already have a problem, you just don't
>> know what the problem is.  Either the previously received
>> out-of-sequence data is bad, or the current packet with the
>> FIN is bad, but you don't know which.
>>
>> As to what to do if this scenario should actually happen:  If
>> these packets were received in sequence, the packet with the
>> FIN would put us into CLOSE-WAIT state.  The data in the
>> packets with SEG.SEQ after the FIN would then be ignored, see
>> page 75 in RFC 793.  So, it seems that the thing to do would
>> be to integrate the data with the FIN, and flush the
>> previously received data that is after the FIN.
>
> Agreed. Just to be clear, the rationale for me suggesting to drop the
> segment with FIN in this case is :
>
> If this is a genuine FIN, it would get retransmitted again. So you  
> know
> what to do the next time, ie., So just give it a chance one time, I
> think this is more safer and robust but YMMV.

Well, now you have to remember that you previously got this FIN, so  
that if it shows up again out of sequence you can do something  
different.  I don't like that additional complexity.  Keep it simple.   
(Or are you saying just keep ignoring the out-of-sequence FIN until  
the holes are filled and it shows up in sequence?)


>>>> 2. FIN was already received and another one arrives pointing
>>>>    into the middle of already queue data (or hole);
>>>>      Ignore the FIN and integrate the data?
>>>>      Ignore the whole segment with the bogus FIN?
>>>>      Integrate the data, move the FIN and flush excess data?
>>>
>>> In the regular case (in-order) if the data is already
>> consumed by the
>>> application and the window has slided, TCP simply ignores the
>>> duplicate data. Now for data sitting in the retransmission
>> queue, we
>>> should probably do the same, I would ignore the whole segment. [ I
>>> know in this case FIN is extra]
>>
>> You should be consistent.  Once again, I'd say integrate the
>> data and FIN into the resequencing queue, and flush the
>> excess data beyond this FIN.
>
> Well, we have already received a FIN, which means that ( going by your
> CLOSEWAIT state example) we don't want to accept any data beyond  
> this as
> per RFC. Now we got a FIN which is way before the current sequence
> number, in which case I would think it makes sense to ignore it. My
> consistency reasons are :-
> - if it would have been received in-order, we would have moved to
> CLOSEWAIT and would have discarded the new FIN as duplicate ( the
> receive window already slided, app might have already the data). TCP
> window slides forward and in this and there is no provision for data
> "overwrite".

But we haven't processed that data & FIN yet, because they came out of  
order.  They are to be processed in SEG.SEQ order, which means the  
earlier FIN is processed first (unless you received something like  
SEG1.SEQ=100,LEN=100,FIN and then SEG2.SEQ=150,LEN=0,FIN, in which  
case the later sequenced FIN would be processed first...)

The bottom line is that if you have two FINs, or data beyond a FIN,  
the connection is screwed up and it probably isn't worth putting much  
effort into dealing with this scenario.  Certainly it is not worth  
trying to optimize.  Your safest bet is to go to a fallback position  
and toss all the suspect data.  So, I'll stick with my original  
suggestion that all the out of sequence data after the earlier  
(sequence numbered) FIN be thrown away.  But we should probably also  
throw away the earlier FIN (and any data that it arrived with).  Then  
we've tossed all the suspect data, and the other side can retransmit  
what it thinks is the correct data, assuming it is able to do so.


			-David


_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm