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

From: [email-masked]
Date: Mon, 29 Jul 2002 19:05:15 +0300

> Hi Iván

	Hi again!

> My problem is that I cannot understand HOW I can use these 
> new DATA chunks for RTT measurements.
> ............
> I may measure the time between DATA and the corresponding SACK,

	That's what you are supposed to do... :-/

> but spec does not always guarantee that SACK will be sent immediately 
> in response to DATA.

	Yes, that's a problem... But there isn't anything you can do against this. The data receiver may delay the SACK up to 200 ms., so you will always have this error in your measures... However you can still apply some kind of "wise" algorithm. For example, if a SACK is acknowledging the receipt of two TSNs that were sent in two separate datagrams, you can consider that the SACK was sent right after receiving the second TSN. A SACK can only be delayed if "everything goes smoothly", i.e., you don't have gaps or duplicate TSNs, and if you have just received one datagram containing DATA chunk/s since the last time it sent a SACK.

	So, a SACK is supposed to have been sent right after receiving the last TSN acknowledged... If you even have gaps, then things are even easier, as the delayed SACK rule is not applied...

	But in any case you can always forget about the comments above and directly do the measure with those 200 milliseconds of error... Being the minimum RTO one second, in the normal situation this shouldn't really make a difference... :-/

	Bye!

	BR Iván Arias Rodríguez

> Sasha
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, July 29, 2002 11:34 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Tsvwg] SCTP RTT measurement question.
> 
> 
> 	Hi Sasha!
> 
> > -----Original Message-----
> > From: ext Sasha Ruditsky [mailto:[email-masked]]
> > Sent: 29. July 2002 18:27
> > To: [email-masked]
> > Subject: [Tsvwg] SCTP RTT measurement question.
> > 
> > 
> > Hi 
> > 
> > I have SCTP RTT measurement question. 
> > RFC 2960 in 6.3.1 C4) suggests:
> > 	...a new RTT measurement MUST be made each round trip...
> > 
> > and in 8.3 
> > 	... chunk which can be used for updating path RTT 
> > 	(usually including first transmission DATA, INIT, COOKIE ECHO,
> > HEARTBEAT etc.)...
> > 
> > 
> > The problem is that I do not see any mechanism to measurement 
> > of RTT each
> > round trip.
> > (Of course I may send HEARTBEAT each RTT, but...)
> > 
> > Please help me understand what do I miss.
> 
> 	At the beginning of the paragraph it says "when data is 
> in flight".
> Of course, this means that if you are transferring data and 
> you have new
> DATA chunks to use as a measure of the RTT, you MUST make 
> that measure.
> Otherwise, just do your best :-).
> 
> 	BR Iván Arias Rodríguez
> 
> > Thanks
> > Sasha
> > 
> > 
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> > 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: David Lehmann <[email-masked]>
Date: Mon, 29 Jul 2002 14:16:18 -0400

> Yes, that's a problem... But there isn't anything you can do against this.

> The data receiver may delay the SACK up to 200 ms., so you will

> always have this error in your measures... 

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.

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: Randall Stewart <[email-masked]>
Date: Tue, 30 Jul 2002 08:30:22 -0500

David:

TCP as well as SCTP as always had this 200ms figured into
the RTT. This is NOT a bad thing but a good thing..

Consider a RTT of 1.0 seconds.. (I know its high but
lets say we are going via a slow boat :>)

Now.. 

I send

------TSN1----->
                |
<---------SACK--
(1.5 sec later)
------TSN2----->

In the above case we WANT the 200ms figured into the RTO (which
is what we get the RTT for) so that we Don't timeout to early.

I know this is a drastic example but I just don't see that
the RTT having an extra 200ms included in its calculation
hurts you... it actually helps since you use RTT to establish
RTO and you want RTO to be high... so you don't do an un-needed time-out

R

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 30 Jul 2002 10:30:00 -0500

David Lehmann wrote:

> 
> Of course, if we are determined to be like TCP, the point is
> academic.
> 

The design goal of SCTP's CC algorithms were to be LIKE TCP. I don't
see that has changed... I may be mistaken.. if so Scott or Allison can
correct me...

R

---

From: Scott Bradner <[email-masked]>
Date: Tue, 30 Jul 2002 12:29:09 -0400 (EDT)

> The design goal of SCTP's CC algorithms were to be LIKE TCP

yup

---

From: David Lehmann <[email-masked]>
Date: Tue, 30 Jul 2002 10:21:44 -0400

Randall Stewart wrote:

> ...

In other words, the sack delay serves the additional function
of an RTO fudge factor. :-)

I thought the "+ 4 * RTTVAR"  in 6.3.1 (C) was supposed to reduce
the unneeded time-outs. The problem with the SACK delay is that it
produces an inaccurate RTT. If the "+ 4 * RTTVAR" is not enough,
maybe the factor of 4 should be increased, rather than
skewing the RTT to get a more practical RTO.

--