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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Nov 2001 15:52:37 -0000

A better view of this is that the server should respond immediately. 200 ms
is the maximum processing delay allowed from received message to transmitted
message. I must admit that I am not particularly keen on this way of trying
to say it. It is not even particularly clear where it is measured (on the
line, between transport layer and SIP, etc.)

If you take this viewpoint, then it is nothing at all to do with the value
of T1.

I would prefer to get rid of this 200 ms value and specify what we really
mean, assuming I have understood the reasoning in the first place.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Shan Lu[SMTP:[email-masked]]
> Sent: 	02 November 2001 16:10
> To: 	'Gonzalo Camarillo'
> Cc: 	'IETF SIP Mailing List'
> Subject: 	RE: [Sip] Bis-05: why 200 ms for 100 Trying
> 
> 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,
> > 
> > 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
> > 
> > Shan Lu wrote:
> > > 
> > > 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
> > 
> > -- 
> > 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]
> > 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Gordon Ledgard <[email-masked]>
Date: Wed, 7 Nov 2001 10:29:45 -0500

Agree entirely. The spec should talk about the generic cases of
maximum acceptable delay of responses in order to define listener
behavior and not get caught up in what happens with trying or
ringing, etc. Time effects, in general, should be pushed down to the
lowest layer of a protocol possible.

Also the spec should be clear about the points in the line where
that measurement takes place, ie. does it include round trip wire
or "once in the box" times.

Gordon

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 10:53 AM
To: 'Gonzalo Camarillo'; 'Shan Lu'
Cc: 'IETF SIP Mailing List'
Subject: RE: [Sip] Bis-05: why 200 ms for 100 Trying

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]