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

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