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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Fri, 22 February 2008 19:40 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 D98DC28CBD6; Fri, 22 Feb 2008 11:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.822
X-Spam-Level:
X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=-1.985, 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 7FzYFQ+WXVJg; Fri, 22 Feb 2008 11:40:47 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D540E28C2B6; Fri, 22 Feb 2008 11:40:15 -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 17C1128CBAB for <tcpm@core3.amsl.com>; Fri, 22 Feb 2008 11:40:13 -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 DQnHnOd7dAjq for <tcpm@core3.amsl.com>; Fri, 22 Feb 2008 11:40:07 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 76A3428CBAF for <tcpm@ietf.org>; Fri, 22 Feb 2008 11:38:44 -0800 (PST)
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2008 11:38:40 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m1MJceFw001590; Fri, 22 Feb 2008 11:38:40 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1MJcep4008568; Fri, 22 Feb 2008 19:38:40 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 11:38:35 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 22 Feb 2008 11:38:16 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Handling of FIN in the reassembly queue
Thread-Index: Ach1fzJWiGGUKy/DTGG4WpfwwP3IiQABM4Yw
References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "David Borman" <dab@weston.borman.com>
X-OriginalArrivalTime: 22 Feb 2008 19:38:35.0879 (UTC) FILETIME=[83E48F70:01C8758A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3323; t=1203709120; x=1204573120; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20Handling=20of=20FIN=20in=20the =20reassembly=20queue |Sender:=20; bh=PSsfIZEw0baFWjJCSstYsrz+CmrASh+1nBipAxf4EGw=; b=zF7RN4SBT5AaPYvkcRxWEBEFfGONsiYgokdil4ma7L1JfMO041G9QYDmph CIv3yALs+XfArKCtUyxMdBmZ8rlgyaoxPf6cmEKCP2Fbhw/BU/UMhiu518t6 J+1AVYuY0G;
Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; );
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

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.

> 
> >
> >
> >>
> >>  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". 

> 
> >
> >
> >>
> >>  3. FIN was already received and another one arrives pointing
> >>     beyond the previous one;
> >>       Ignore the FIN and integrate the data (if within 
> previous FIN)?
> >>       Ignore the whole segment with the bogus FIN?
> >>       Integrate the data and move the FIN?
> >
> > Ignore the FIN.
> 
> Being consistent, throw away this new packet, since it is 
> beyond the previous FIN.

Yes, when I said ignore I meant discard, sorry should have been clear.

I would think it makes sense to throw away the FIN whether it is beyond
or before the previous FIN, to make things consistent. YMMV.

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