Subject: Transaction packet count Was: Re: Re : RTSP

From: "Karl Auerbach" <[email-masked]>
Date: Wed, 16 Oct 1996 12:42:18 -0700

One relatively small point that I have not seen mentioned in the exchange
of messages is the overall packet count.

Many TCP implementations aren't really all that good about piggybacking
acks onto outgoing data.  Hence, even on an loss-free network, what from
the application appears to be a simple action-response interaction often
causes the exchange of four packets, two of which simply bear
acknowledgment bits.  A good TCP implementation can, of course, improve
this to three packets.  This compares to the two packets required to
support a UDP based transaction.  (Again, I'm assuming an error-free
network as the normal case, which, as a practical matter, is true most of
the time.)

We've been having this same connection versus connectionless argument for
years in the snmp community.  (And in that community I'm an advocate of the
connection oriented approach, but I'm still listening here.)

		--karl--

---

From: [email-masked]
Date: Wed, 16 Oct 1996 17:21:53 -0700

Bob Braden told me that his analysis of TCP in BSD was
10 packets for a simple exchange, which could be optimized 
down to 6:

Here are the 10:

	SYN ->
		<- SYN+ACK
	ACK ->
	(request)->
		<- ACK
		<- (response)
	ACK ->
	FIN ->
		<- FIN+ACK
	ACK ->

Down to 6:

	SYN ->
		<- SYN+ACK
	ACK+(request)->
		<- ACK+(response)
	FIN+ACK ->
		<- FIN+ACK
	ACK ->

 or

	SYN+(request) ->
		<- SYN+ACK
	ACK ->
		<- ACK+(response)
	FIN+ACK ->
		<- FIN+ACK
	ACK ->

Whether you piggyback onto outgoing data or not depends on 
whether you stall the ACKs in hopes of getting data to
send along too.

The other problem is that you'd like to send a

	SYN+(request)+FIN ->

but then the next packet would be

		<- SYN+ACK+FIN

and the connection would close before the data would be delivered to
the application (must wait for the ACK after the SYN, three-way
handshake for TCP).

How do you get this down further??

Joe
----------------------------------------------------------------------
Joe Touch - [email-masked]		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

---

From: "Karl Auerbach" <[email-masked]>
Date: Wed, 16 Oct 1996 18:45:05 -0700

> 10 packets for a simple exchange, which could be optimized 

With respect to the actual packet cost of transactions over TCP, I think
that we should assume that TCP connection setup and teardown are done "a
long time ago" and "a long time in the future".  In other words, let's
ignore the cost of TCP startup and teardown handshakes and assume that the
packet cost of TCP startup/teardown, when amortized over a number of
application data transactions, approaches zero and may consequently be
ignorred.

		--karl--

---

From: [email-masked]
Date: Wed, 16 Oct 1996 20:30:51 -0700

> application data transactions, approaches zero and may consequently be

I am stuck in HTTP-mode where every transaction
can be its own connection, which is what I outlined above.

(sorry if this confused matters)

Joe

---

From: Arlie Davis <[email-masked]>
Date: Thu, 17 Oct 1996 10:18:41 -0400

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Wednesday, October 16, 1996 11:30 PM
>To: 	[email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: Transaction packet count  Was: Re: Re : RTSP
>

True.  Don't forget, though, that many HTTP clients and servers support
keep-alive now, which uses the TCP connection for more than one
transaction.