Subject: [tcpm] Settling Time and RFC3517bis

From: Anthony Sabatini <[email-masked]>
Date: Wed, 1 Aug 2012 15:23:26 -0400

Settling Time is the concept of how long we wait for an out of order packet.  It has been an unnamed mainstay of IPv4 from the beginning, masquerading under the name "Fragmentation Reassembly Timer" but at the TCP level its physical existence has gone unacknowledged.

Settling Time is rather easy to calculate as it has a ceiling of .25*RTT (any number over that and you are in retransmission territory) and a floor of Fragmentation Reassembly Time * 1.25 (need to leave enough time to process reassembled packet).  Obviously the lower number is better and there are probably thousands of emails on how  to set the Fragmentation Reassembly Timer properly.

The point here is we are dancing around issues by saying we wait for multiple ACKs before a SACK block is processed, you are badly simulating reassembly delay.  Better to act on the first appearance of a hole in the sequence but delay the actual call for retransmission by Settling Time to see if the world has changed before you issue the retransmission.  Also the time represented by multiple ACKs is extremely variable,  short segments and random times for WOW, long segments and continuous for file transfer. 

Note for the record a DELAY TIMER is not in and of itself an event, it is delaying and existing event, therefore its expiration does not have any implications of its own, the event already  happened.

Tony

Sent from my ASUS Pad

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Aug 2012 14:14:09 -0700

On 8/1/2012 12:23 PM, Anthony Sabatini wrote:
> Settling Time is the concept of how long we wait for an out of order packet.

That's already called reordering time. Settling time is a term from 
analog electronics/optics, and I don't see a good reason to import it here.

> It has been an unnamed mainstay of IPv4 from the beginning,
> masquerading under the name "Fragmentation Reassembly Timer" but at the
> TCP level its physical existence has gone unacknowledged.

There has been no masquerading, but there appears to be confusion ;-)

Fragmentation reassembly is based on the time between the arrival of the 
first fragment of a set (FWIW, I mean "first" as "first in time", not 
"the packet with an offset of 0") and the last (again, in time, not the 
fragment where MF=0), and is not affected at all by the order of the 
arrival of the fragments.

In TCP, the reordering is of segments, and is tolerated by the receive 
window.

> Settling Time is rather easy to calculate as it has a ceiling of
> .25*RTT (any number over that and you are in retransmission
> territory)

TCP should never do anything RTT-based in less than a full RTT. It has 
no business retransmitting in less than one RTT.

> and a floor of Fragmentation Reassembly Time * 1.25 (need
> to leave enough time to process reassembled packet).

The additional time is whatever time is needed to:
	- complete reassembly
	- get the resulting IP datagram to TCP for processing

This should be on the order of microseconds, vs. milliseconds for most 
RTTs; 25% of the reassembly timer is thousands of time larger.

However, again, the issue for TCP is the segment reordering time, which 
does not necessarily have anything to do with the reassembly time. E.g., 
even atomic (non-fragmented) segments can arrive out of order.

> Obviously the
> lower number is better and there are probably thousands of emails on
> how  to set the Fragmentation Reassembly Timer properly.
>
> The point here is we are dancing around issues by saying we wait for
> multiple ACKs before a SACK block is processed, you are badly
> simulating reassembly delay.  Better to act on the first appearance
> of a hole in the sequence but delay the actual call for
> retransmission by Settling Time to see if the world has changed
> before you issue the retransmission.  Also the time represented by
> multiple ACKs is extremely variable,  short segments and random times
> for WOW, long segments and continuous for file transfer.

As the use of multiple concurrent paths becomes more common, 
out-of-order segment receipt becomes the norm. Jumping the gun on 
retransmitting holes could turn a mild reordering situation into a 
congested system quickly.

I see no reason to act on holes on timescales shorter than 1-2 RTTs.

Joe

> Note for the record a DELAY TIMER is not in and of itself an event,
> it is delaying and existing event, therefore its expiration does not
> have any implications of its own, the event already  happened. >
> Tony
>
> Sent from my ASUS Pad
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>