Subject: RE: [Sip] Connection: Keep-Alive

From: "Paul D.Smith" <[email-masked]>
Date: Mon, 17 Nov 2003 13:31:19 -0000

All,

Can I just flag up that in one respect, UDP can have advantages over TCP (or
any other reliable transport).  Once the path from sender to receiver
machines becomes congested, TCP builds up a queue of pending SIP requests.
Note that this "queue" consists of messages queued both at the receiver (if
receiver is unable to handle received requests at a rate equal or in excess
of arrival rates) and the sender (if the network itself or the connection to
the receiver is congested).  Quite where messages are queued can be
immaterial.

Ultimately, the time taken for a request to move from the bottom of this
queue to the top can exceed the 32s (64 * T1) request timeout imposed by RFC
3261 and policed by the sender.  Once this occurs, _all_ SIP requests sent
to the receiver machine then fail until congestion subsides and the "bottom
to top" time falls below 32s (64 x T1).

By comparison, a UDP stack drops frames when congested so many SIP requests
will be dropped and fail but some will be get lucky and get processed by the
receiver.  As a result, under severe congestion, UDP can have _better_
request success rates that TCP.

As is currently being discussed, congestion can have many causes and solving
it is very tricky, if not impossible across the entire network.  I just
wanted to flag that using a reliable transport can introduce some problems
as well as solving others.

Finally, a question for the group to consider.  If we are using a reliable
transport, does it even make sense to enforce the 32s (64 x T1)  timeout?
It seems that if we have a reliable transport, we should accept that the
request _will_ reach the next hop and that a response _will_ come back
(unless the connection fails - which we should be able to detect) and
therefore the 32s timeout might be unneccessary.

Paul D.Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: 13 November 2003 12:52
To: SIP (E-mail)
Subject: RE: [Sip] Connection: Keep-Alive

I also agree that a document is important.  The consensus in the room
yesterday was am emphasis on TCP usage due to the known limitations of UDP.
Some form of BCP might go a long way to promoting it's currently limited
usage.
 
Chris.

	-----Original Message----- 
	From: Jonathan Rosenberg [mailto:[email-masked]] 
	Sent: Thu 13/11/2003 07:42 
	To: [email-masked] 
	Cc: 'Vijay K. Gurbani'; 'Christian Stredicke'; [email-masked];
[email-masked] 
	Subject: Re: [Sip] Connection: Keep-Alive

	Sorry for not being clear - I wasnt saying we DONT want a document.
At
	the meeting today, I advocated (and I think many others agreed) for
	creation of a document. In particular, I think it makes sense to
have
	a proposed standard document that describes all of the issues with
	getting tcp to work. This would presumably be an expansion of the
	existing connect-reuse draft. It needs to be PS since there is
	normative behavior associated with many parts of it.
	
	-Jonathan R.
	
	Sean Olson wrote:
	
	> Actually, many implementations are not doing this unfortunately. A
BCP is
	> not a bad idea.
	>
	> -----Original Message-----
	> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan
	> Rosenberg
	> Sent: Wednesday, November 12, 2003 11:12 PM
	> To: Vijay K. Gurbani
	> Cc: Christian Stredicke; [email-masked]; [email-masked]
	> Subject: Re: [Sip] Connection: Keep-Alive
	>
	>
	>
	> Vijay K. Gurbani wrote:
	>
	>
	>
	>>>In any case the behavior of the UAC as well as the proxy needs to
be
	>>>(re)defined, I think the current TCP specification does not allow
a
	>>>permanent connection.
	>>>
	>>>Any thoughts on this?
	>>
	>>
	>>At the Atlanta IETF, it was decided that we will open a bug
against
	>>rfc3261 to provide more information on TCP connection handling.
	>
	>
	> Well, in particular, it was concluded that signaling "please keep
this
	> connection open" was not needed at all. Rather, the server should
keep the
	> connection open as long as it could, and only close it if it ran
out of
	> resources. Since there was no benefit to closing it prematurely
(extra costs
	> of setting it up again), and since signaling the desire for
persistence
	> could not be used to force the server to keep it open if the
server ran out
	> of resources, the signaling was not needed.
	> Indeed, the observation was that many implementations in any case
were doing
	> this; it was just unclear in the spec.
	>
	> -Jonathan R.
	>
	
	--
	Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
	Chief Technology Officer                    Parsippany, NJ
07054-2711
	dynamicsoft
	[email-masked]                     FAX:   (973) 952-5050
	http://www.jdrosen.net                      PHONE: (973) 952-5000
	http://www.dynamicsoft.com

	_______________________________________________
	Sip mailing list  https://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

J*fj)b	bm끶?0쇛'~ffX)"8bX鬶+DYׯzZ)	ay���+y">-%R৛Wz{h,r䉉ny۟zb椢{(˫
*T"禘'~~把{^hgg'끶bqbz

_______________________________________________
Sip mailing list  https://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: "David R. Oran" <[email-masked]>
Date: Mon, 17 Nov 2003 10:26:02 -0500

Unlike Paul's earlier message on 3-way handshaking, with which I disagreed, 
this post makes a very important point with which I whole-heartedly agree.

When the signaling is single-hop, it may in fact make sense to disable the 
request timers. Unfortunately, when the signaling is multi-hop this doesn't 
work and it isn't clear what to do.

One of the objections to 3-way handshakes (aside from the one Paul made in 
his earlier post) is the additional state in proxies. If we in fact do 
enough surgery to SIP to introduce 3-way handshakes on non-invite 
transactions, perhaps we can also at the same time introduce a header hint 
on non-invite transactions which indicate to proxies that it is safe to 
operate statelessly on such transactions if the proxy so chooses.

Dave.

--On Monday, November 17, 2003 1:31 PM +0000 "Paul D.Smith" 
<[email-masked]> wrote:

> All,
>
> Can I just flag up that in one respect, UDP can have advantages over TCP
> (or any other reliable transport).  Once the path from sender to receiver
> Note that this "queue" consists of messages queued both at the receiver
> (if receiver is unable to handle received requests at a rate equal or in
> excess of arrival rates) and the sender (if the network itself or the
> connection to the receiver is congested).  Quite where messages are
> queued can be immaterial.
>
> queue to the top can exceed the 32s (64 * T1) request timeout imposed by
> RFC 3261 and policed by the sender.  Once this occurs, _all_ SIP requests
> sent to the receiver machine then fail until congestion subsides and the
> "bottom to top" time falls below 32s (64 x T1).
>
> By comparison, a UDP stack drops frames when congested so many SIP
> requests will be dropped and fail but some will be get lucky and get
> processed by the receiver.  As a result, under severe congestion, UDP can
> have _better_ request success rates that TCP.
>
> As is currently being discussed, congestion can have many causes and
> solving it is very tricky, if not impossible across the entire network.
> I just wanted to flag that using a reliable transport can introduce some
> problems as well as solving others.
>
> yesterday was am emphasis on TCP usage due to the known limitations of
> UDP. Some form of BCP might go a long way to promoting it's currently
> limited usage.
>
> Chris.
>
>
> 	Sorry for not being clear - I wasn't saying we DONT want a document.
> At
> J*fj)b	bm??0?'~ffX)?"8bX?+DY?zZ)	ay?+y">-%R?Wz{h,r?ny?zb?{(?
> *T"?'~~?{^hgg'?bqbz
>

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]