Subject: RE: [Sip] Proposed closure of open issue #71: RTT estimation w/ Timestamp

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Sep 2001 02:16:34 -0400

Responses inline.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 1:03 PM
> To: Jonathan Rosenberg
> Cc: 'Rohan Mahy'; [email-masked]
> Subject: Re: [Sip] Proposed closure of open issue #71: RTT 
> estimation w/
> Timestamp
> 
> > Well, its kind of just punting the problem. If we have 
> something in there
> > about this at all, we should describe how it can be made to 
> work in a
> > sensible way.
> 
> 
> The problem here is that if the UAC does not compute a new timestamp
> every time it retransmits a request, the RTO calculated will be
> inaccurate.
> 
> This problem is present in TCP as well, and implementations 
> can resolve
> it in two ways. 
> 
> 1) The first one is the simple and easy solution. It is what TCP tahoe
> and TCP Reno do. They do not use retransmitted segment to calculate
> RTOs. When a segment is retransmitted the ACK for that segment is not
> taken into consideration for RTT measurement. Therefore, a 
> SIP UAC would
> do the same with retransmitted requests. Just forget about 
> the timestamp
> in the response.

Ah, I didn't realize tahoe and reno worked this way. Thats helpful to know.

> 
> 2) This is the accurate but complicated method. We update the 
> timestamps
> everytime we retransmit something. TCP Las Vegas uses timestamps in
> order to compute a very accurate RTO. Simulations show that TCP Las
> Vegas achieves a higher throughput, but it is not widely 
> implemented...
> folks prefer the less effective but simpler algorithm. 
> Applying this to
> SIP, a SIP UAC might update the timestamps in its retransmissions, but
> that would be a pain.
> 
> 
> I would outline in bis both possible behaviors and then let 
> implementors
> choose which one they want to use.

Well, quoting RFC 1958:

3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

So, let us pick and document one. I propose #1. If its good enough for
tahoe, its good enough for us.

So, unless I hear otherwise within TWO WEEKS, this change will be made to
bis.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 26 Sep 2001 13:33:53 -0400

Isn't this purely an internal mechanism. If there's no externally
observable difference I don't see why the spec would bother to go into
this. A simple impl might go for #1 and a higher end UA could go for #2
and everything is just hunky dory.

Anders