Subject: [Tsvwg] overlapping TCP segments during reassembly

From: Murali Bashyam <[email-masked]>
Date: Mon, 25 Aug 2003 18:56:48 -0700

Hi

Is there any guidelines outlined by any TCP RFC's  for determining what
data in the sequence space to keep and what to drop during TCP out of
order packet reassembly when there are overlaps? The BSD code tries to
trim the incoming segment when there is an overlap with a previous
segment in sequence space, and trims the already queued segments when
there is an overlap with succeeding segments in sequence space. I was
curious abt the motivation behind this strategy.

Murali

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 26 Aug 2003 16:44:17 -0500

> curious abt the motivation behind this strategy.

Certain things are implied:

1) overlaps indicate retransmissions.

2) multiple valid segments must all have the same value
    for any given byte in the TCP stream, i.e. the
    retransmit can only correct transmission errors
    it cannot "fix" the data.

3) you can only deliver a given byte to the TCP consumer once.

So, if you have a buffered but undelivered sequence, should
you replace it with new content? Well, since you know the
values are the same, why not optimize the copy by simply
not performing it?

Caitlin Bestler - [email-masked] - http://asomi.com/

---

From: Murali Bashyam <[email-masked]>
Date: Tue, 26 Aug 2003 18:55:25 -0700

> values are the same, why not optimize the copy by simply

Right,  based on these assumptions, that was the policy i was leaning
towards, can i simply apply all the trimming  i need to do on the  incoming
segment and always honour the already buffered data? Would this end up
violating any delivery semantics?

Murali