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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Fri, 22 February 2008 02:25 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 EFAC13A6C16; Thu, 21 Feb 2008 18:25:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level:
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-1.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 gkce7ebbMDen; Thu, 21 Feb 2008 18:25:04 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11753A6C45; Thu, 21 Feb 2008 18:24:51 -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 9FD323A6D1A for <tcpm@core3.amsl.com>; Thu, 21 Feb 2008 18:24:46 -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 Esm-VNSebY8t for <tcpm@core3.amsl.com>; Thu, 21 Feb 2008 18:24:35 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5158A28CAA1 for <tcpm@ietf.org>; Thu, 21 Feb 2008 18:24:08 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Feb 2008 18:24:04 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1M2O4jk009662; Thu, 21 Feb 2008 18:24:04 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1M2O4R2016445; Fri, 22 Feb 2008 02:24:04 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 18:24:03 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 21 Feb 2008 18:23:44 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <47BE04A2.8000000@freebsd.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Handling of FIN in the reassembly queue
Thread-Index: Ach03tT4x2WBgSSETUOekVd2cO4zBAAECYNQ
References: <47BE04A2.8000000@freebsd.org>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Andre Oppermann" <andre@freebsd.org>, <tcpm@ietf.org>
X-OriginalArrivalTime: 22 Feb 2008 02:24:03.0925 (UTC) FILETIME=[FE200850:01C874F9]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3449; t=1203647044; x=1204511044; c=relaxed/simple; s=sjdkim1004; 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=YGPM5zDKo3wLSN//Ndm661ivAUMCrRxur/qEV0QhUko=; b=DwmekBkhLLKX2MEg+ZPRxNkoMlimJ5qMSFthmf5utz0YHZUSpClXRurqcV l5tT1GVtPRzMoMs0+qEWbMOUXfLA6+WGKddBG9DPxN52f8E3CC5nU93Q8FV6 e9STfENu2qLUPNaWRqypFD3zkJSy0B1HWUniqKkNXL1kwtpYeKuMI=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
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

Andre,
        
> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Andre Oppermann
> Sent: Thursday, February 21, 2008 3:09 PM
> To: tcpm@ietf.org
> Subject: [tcpm] Handling of FIN in the reassembly queue
> 
> The TCP reassembly queue is very good at handling and queuing 
> out of order data.  However correctly handling and queuing an 
> out of order FIN seems to be a bit tricky for a number of 
> (broken) edge cases:
> 
>   1. FIN points into the middle of already queuedh 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?

I would think discarding the FIN would be fine, but if the FIN gets
retransmitted again, then this puts a question mark on the data sitting
on the reassembly queue and in such cases we can possibly conclude the
data in the reassembly queue is bogus? 

This brings up another question  : suppose a TCP stack has sent s1, s2
s3 and s3 with FIN, assume s1 is dropped, is it ok to retransmit s1 with
FIN bit set (some stacks might see the state and blindly color the
segment with FIN) I don't think this is allowed? 

> 
>   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]

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

> 
>   4. FIN without data pointing beyond already queued data;
>        Queuing a standalone FIN w/o data and not directly attaching
>        to the end of the queue complicates the implementation a lot.
>        Is it acceptable to ignore the FIN for the moment and have it
>        retransmitted (with or without data) later?

Actually it depends on how the reassembly queue is implemented, if you
have a descriptor block for each data element sitting in the reassembly
queue, then you simply set a bit that indicating FIN is present which
you could do for the last segment sitting in the reassembly queue.

> 
> For reference the traditional reassembly queue implementation 
> doesn't care and queues any segment with FIN in any place.  
> Depending on the hole situation this can lead to strange 
> behavior and only ever partly dequeued data.
> 
> Any input, insight and discussion welcome. :-)

I think it is an interesting discussion for sure :-). There are other
cases which come to mind as well (half-close and simultaneous close
cases)

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