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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Sep 2001 03:04:04 -0400

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Saturday, September 08, 2001 3:04 PM
> To: [email-masked]
> Subject: [Sip] Proposed closure of open issue #71: RTT estimation w/
> Timestamp
> 
> 
> Hi,
> 
> I am proposing closure of open issue #71 on RTT estimation using the 
> Timestamp header.
> The open issue is that the spec doesn't describe how to 
> estimate RTT in the 
> face of retransmits.
> 
> I propose changing the following text to make this a local 
> implementation 
> issue:
> 
> From:
> "The timestamp is used by the client to compute the RTT to 
> the server so it 
> can adjust the timeout value for retransmission"
> 
> To:
> "The timestamp MAY be used ...
> 
> this clarifies that this is purely optional behavior and local 
> implementation heuristics.
> 
> comments or objections?

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.

-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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Sep 2001 20:03:25 +0300

Hello,

> about this at all, we should describe how it can be made to work in a

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.

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.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]