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

[David Borman <[e-mail]>]

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
[e-mail]
http://www.ietf.org/mailman/listinfo/tcpm