Subject: [Sip] Bis-05: why 200 ms for 100 Trying

From: "Shan Lu" <[email-masked]>
Date: Thu, 1 Nov 2001 10:34:49 -0500

Hi all,

Section 17.2.1, line 2702, mandates a 100 Trying be sent by the
transction server within 200 ms.

Q1: What is the rationale behind this magic value, 200 ms? Note that all
other timer values in transaction FSM are specified with a DEFAULT,
meaning they may be modified by implementations. Then why is this one
hard coded?

Q2: Assume T1 = RTT = 500 ms. If you work out the math, it turns out
that a 100 Trying sent exactly 200 ms (conformant to the above rule)
after the INVITE will result in two INVITEs (initial plus one retrans)
and hence two 100 Trying, assuming TU can't produce any 1xx or final
response. The same can be achieved if a 100 Trying is sent exactly 500
ms after the initial INVITE. So the conclusion is that if you want to
quench request retransmissions as soon as you can, you MUST send 100
Trying IMMEDIATELY. On the other hand, if you can tolerate some
retransmission, you might just as well wait for 500 ms (T1) and hope
that a meaningful 1xx (>100) response can be supplied by the transaction
user.

Regards,

Shan Lu
sentitO Networks

_______________________________________________
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: Thu, 01 Nov 2001 19:31:06 +0200

Hello,

In almost all the scenarios the server does not have a way of knowing if
a final response will be produced within 200 ms, so the 100 trying is
sent immediately.

However, a particular server might know that it usually sends final
responses back pretty quick (it might now have to interact with a human
user, for instance). Then, it uses what TCP calls "delayed ack". This
saves some traffic, because the server will send one instead of 2
responses back.

About the "magic" value of 200 ms: It is impossible to give an exact
value for this timer because it would depend on the T1 timer chosen by
the client. However, for the default value (T1=500 ms), waiting 200 ms
makes perfect sense. 

In the example you give there is a 500 ms RTT. Whereas I am not saying
that this is impossible, the RTT is not likely to be so big. Crossing
the Atlantic over the public Internet has a RTT of 150 ms aprox. Take
into account that 100 Trying is sent hop by hop.

Cellular access could give you a high RTT as well. However, the first
server receiving the INVITE is not the one answering with a final
response, so it will no use the 200 ms timer. It will respond
immediately.

Therefore, I do not see any problem with this timer.

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]

---

From: "Shan Lu" <[email-masked]>
Date: Fri, 2 Nov 2001 11:10:50 -0500

Hi,

It looks like the 200 ms is an educated guess at best and the selection
of this value really is tied to the difference between T1 and RTT,
although bis-05 clearly states that T1 is an estimate of RTT, not
RTT+200ms. Since T1 can be modified and RTT certainly varies between
applications, I don't see any reason why this value should be kept fixed
at 200 ms.

Another thing that bothers me is the way this 200 ms is presented in
bis-05. Section 17.2.1, line 2703, ".. Must generate 100 Trying unless
it knows TU will generate a provisional or final response within 200
ms." 

How do you verify whether transaction knows something about TU? If no
response is produced within 200 ms, then is it a violation of the
protocol? If the answer is yes, then it will be far more clear to state
that "Must generate 100 Trying within 200 ms". Or does the original
sentence imply that a 100 Trying must be sent IMMEDIATELY since really
there is no way for transction to know anything from TU? If so, this
intention should be cleary stated.

Regards,

Shan Lu
sentitO Networks

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2001 12:31 PM
> To: Shan Lu
> Cc: IETF SIP Mailing List
> Subject: Re: [Sip] Bis-05: why 200 ms for 100 Trying
> 
> 
> Hello,
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Nov 2001 20:47:15 +0200

Hello,

> applications, I don't see any reason why this value should be kept fixed

First of all, the server does not know the T1 used by the client.

Second, TCP uses a fixed value of 500ms for the delay ACK algorithm.
Therefore, if a fixed value os good enough for TCP, it is good enough
for us. We are not trying to build a transport layer for UDP which is
better than a complete transport protocol.

> How do you verify whether transaction knows something about TU?

I still do not see any problem here. In 95% of the situations the server
transaction does not know whether the final response will come in 200ms.
Therefore, it will send the 100 Trying without waiting for anything.

Note that waiting zero seconds is completely valid according to bis-05.

> If no
> protocol? 

If your transaction layer thinks that the final response from the TU
will come in 200 ms but it finally does not come that soon then the
server transaction layer itself generates the 100 Trying.

Where do you see a problem?

Regards,

Gonzalo

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 5 Nov 2001 11:01:15 -0500

Hi,

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gonzalo Camarillo
> Sent: Friday, November 02, 2001 1:47 PM
> To: Shan Lu
> Cc: 'IETF SIP Mailing List'

True. But this situation is not unique. Look at section 17.1.1.2, line
2590. Although Timer D in INVITE client transaction is dependent on
values used at the server side, a default value (16s, T3) is specified
anyway. 

> better than a complete transport protocol.

If TCP is so great, why don't we use TCP for call setup then, just like
H.323? (Sorry, bad word :-) And why did you change from 500 ms to 200
ms? Anyhow, I'd like to reiterate my original point which is quoted at
the start of this message: this timer should be given a default value
and be allowed to change. 

> Therefore, it will send the 100 Trying without waiting for anything.

How do you know whether an implementation falls within your 95% category
or belongs to the other 5%? I don't think a standards document should
specify conformity based on statistics.

> server transaction layer itself generates the 100 Trying.

How did you arrive at this interpretation based on the text at line
2703? Figure 7 doesn't indicate this behavior either.

Regards,

Shan Lu
sentitO Networks