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

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