Subject: Re: [Tsvwg] SCTP RTT measurement question.

From: Laurent Glaude <[email-masked]>
Date: Thu, 01 Aug 2002 08:46:13 -0400

I see this as two situations:

(1) - In the case of steady traffic, then the 200ms delay incurred by 
the delayed ack timer seldom occurs, because instead a sack is sent for 
every two data packets received (and the packets come in quickly). Thus 
RTT measurements from data packets and heartbeats are bound to give a 
comparable result.

(2) - In the case where the 200ms expires frequently, I don't see a 
problem for the reason that the traffic is very, very low (ie with 200ms 
delayed ack, it means 5 packets or less per second ).

-Laurent

Brian F. G. Bidulock wrote:
> David,
> 
> Good point.  HEARTBEAT RTT calulcations do no include SACK
> delays.  It appears that when failing over from a primary
> destination to a secondary, the secondary could have a more
> agressive RTO than should be expected if the peer is delaying
> SACKs.  This could result in excessive retransmissions for a
> period immediately after the failover: which, of course, is
> the worst time to be having excessive retransmissions.
> 
> There is a case for loadsharing over avialable destinations.
> 
> --brian
> 
> On Wed, 31 Jul 2002, David Lehmann wrote:
> 
> 
>>Vern Paxson wrote:
>>
>>
>>>>What if we used one of the unused bits of the chunk flags in the DATA
>>>>chunks to tell the receiver to "sack the packet containing this DATA
>>>>chunk without delay"?  Then we could get more accurate measurements.
>>>>
>>>
>>>The point of measuring RTT is not to measure the network-layer round trip
>>>time, but to estimate how long it takes to get feedback for a transmitted
>>>data packet.  For that use, the RTT *should* include delays such as delayed
>>>acknowledgements, because that's part of what contributes to the overall
>>>feedback delay.
>>
>>
>>This makes sense for a single homed endpoints like TCP.  However, I am
>>questioning the logic for multihomed endpoints.
>>
>>e.g. If I have a peer endpoint with four destination IP addresses,
>>all of which run through four equal networks, I should have similar
>>SRTT values for all destinations.  So, when switching destinations
>>for the DATA, either for failover, retransmit, or user request, the
>>RTO calculation should produce a similar value for the new
>>destination as it did for the old.
>>
>>However, this is not the case.  The primary destination can have a
>>significantly larger SRTT than the other destinations, on which
>>only the heartbeats flow. So, when using another destination for DATA,
>>the RTO calculation is initially much lower (ignoring the default
>>minimum) on this new destination.
>>
>>
>>IMHO, since we went through the expense to calculate the SRTT on the
>>non-DATA destinations, we should be able to use that information to
>>calculate the same practical RTO for the new destination as we would
>>if the DATA has been flowing on that new destination all along.
>>This requires the RTT to have the same meaning on all destinations.
>>
>>-- 
>>
>>David Lehmann                          Ulticom, Inc.
>>AOL/Yahoo IM: davidULCM                1020 Briggs Road
>>1-856-787-2729                         Mt. Laurel, NJ 08054   USA
>>
>>
>>
>>_______________________________________________
>>tsvwg mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 

-- 
Laurent Glaude
Software Engineer, Performance Technologies
[email-masked] - http://www.pt.com

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 02 Aug 2002 09:16:04 -0500

> destination as it did for the old.

It is true that the RTO estimate may be off by 200ms on the
primary destination as compared to the HB'ing 3 idle destinations.. but
the real question is will 200ms make any difference and does it matter?

Consider:

1) RTO.min has a recommended value of 1 second. So in
   the case of say a 50ms RTT or even a 100ms RTT... adding
   200ms to it will still result in a RTO.min being put in place.

2) Not always does the RTO estimate get this 200ms variance
   added in. If there is ANY loss your RTT is going to drift
   downwards on your primary destination.. at least during
   the time that the loss is being recovered from (assuming
   a fast retransmit here). Or if you get two packets you
   stop the 200ms timer and send a SACK... So if you are really
   sending a lot of data (* a lot being defined as more than
   5 packets every second) the 200ms quickly comes out of the RTT.

3) One could argue to add a 200ms delay in HB responses then
   but of course this would NOT solve this little bubble (assuming
   it is a real issue of which I am not convinced)... this is
   due to the fact of (2) above... so if we added a 200ms HB
   delay we would ALWAYS have an extra 200ms calculated in
   and thus it would always be towards the high side as
   compared to either a lossy primary or where > 5 packets
   a second were being sent.

4) Laurent, I think, really hit the nail on the head in that the
   only time the 200ms is going to be showing up on a regular
   basis in your RTO will be when you are sending 5 or less 
   packets a second. If you are sending such little traffic
   does it really matter that the RTO may be a bit high? I think
   not..

I really think this is a non-issue :-) and nothing to be
concerned about.. unless there is something I am missing in
this thread :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)