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

From: Vern Paxson <[email-masked]>
Date: Tue, 30 Jul 2002 09:55:52 -0700

> 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.

		Vern

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

---

From: David Lehmann <[email-masked]>
Date: Wed, 31 Jul 2002 08:53:00 -0400

> acknowledgements, because that's part of what contributes to the overall

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Jul 2002 18:06:17 -0600

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

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦