On 2006-04-22, Michael Zedeler wrote:
> Hello eerybody.
>
> I need to know approximately how much overhead I can expect when sending
> data using TCP. In other owrds, if I send a payload using TCP, how much
> extra traffic will it result in on the ethernet level?
>
> The reason I am asking, is that I need to do a cost analysis of sending
> data from mobile units using either SMS or GPRS. If I use SMS, I have a
> fixed number of chars per message, which in turn has a fixed cost. Using
> GPRS, I have a cost per. megabyte transferred, but that is counting
> everything that goes over the air.

This was a really good question to ponder. My response here is a
little late, apologies, just subscribed to this group...

TCP's setup really isn't that much - I estimate really roughly around
< 256 bytes for the connection setup with a bit of payload in it -
the first three packets setup the network socket, handshake and pass
options for the session, and then data payloads continue at the
agreed upon sizes across the session subject to the physical limits
of the interface signalling (Ethernet, approximately 1500 bytes,
usable TCP payload 1460 bytes, etc.). TCP includes negotiation inside
each packet to improve performance (TCP windowing) although the
performance of this widely varies with the TCP/IP software
implementation. A possible worst-case scenario in a lossy socket
connection or lousy stack implementation is that each data packet
requires a 64-128 byte "zero payload" to ACK acknowledge the packet
received - I don't know if your data stream is mostly one-way or
two-way.

Another plausible downside to TCP is that retransmission can't really
be bounded without a decent amount of tuning - TCP will "back off"
and not constantly try to retransmit, but it will keep trying and
sockets can "stall" where recovery doesn't occur or lots of
retransmissions occur - again, this is dependent on the TCP/IP stack
and application above it.

I'm not sure about SMS messaging, but from your post I have a leaning
towards it fiscally for your application because it sounds like
you'll get a consistent price-per-message, and consistent cost
perhaps for a retransmitted message. With TCP, it could vary for all
the reasons above, especially if you get a bunch of slow or lossy
connections requiring a high retransmission count.

Hope this helps a bit.

/dmfh

----
__| |_ __ / _| |_ ____ __
dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----

Hi DMFH.

DMFH wrote:
> On 2006-04-22, Michael Zedeler wrote:
>
>>I need to know approximately how much overhead I can expect when sending
>>data using TCP. In other owrds, if I send a payload using TCP, how much
>>extra traffic will it result in on the ethernet level?
>>
>>The reason I am asking, is that I need to do a cost analysis of sending
>>data from mobile units using either SMS or GPRS. If I use SMS, I have a
>>fixed number of chars per message, which in turn has a fixed cost. Using
>>GPRS, I have a cost per. megabyte transferred, but that is counting
>>everything that goes over the air.
>
> This was a really good question to ponder. My response here is a
> little late, apologies, just subscribed to this group...

I'm just happy to see your reply. It is not too late to be useful.

> TCP's setup really isn't that much - I estimate really roughly around
> < 256 bytes for the connection setup with a bit of payload in it -
> the first three packets setup the network socket, handshake and pass
> options for the session, and then data payloads continue at the
> agreed upon sizes across the session subject to the physical limits
> of the interface signalling (Ethernet, approximately 1500 bytes,
> usable TCP payload 1460 bytes, etc.). TCP includes negotiation inside
> each packet to improve performance (TCP windowing) although the
> performance of this widely varies with the TCP/IP software
> implementation. A possible worst-case scenario in a lossy socket
> connection or lousy stack implementation is that each data packet
> requires a 64-128 byte "zero payload" to ACK acknowledge the packet
> received - I don't know if your data stream is mostly one-way or
> two-way.

It would be two-way, but there is no negotiation. First one side
delivers a bunch of data and then the other side returns another bunch
of data. Connection closes.

I understand what you write so that we'll probably be transmitting a low
number of packets each sized at 1500 bytes. What about teardown? Doesn't
that also cost about three packets? That would total 3 (setup) +
payloads + 3 teardown = 9000 bytes + x*128 bytes overhead (x being the
number of payload packets.

> Another plausible downside to TCP is that retransmission can't really
> be bounded without a decent amount of tuning - TCP will "back off"
> and not constantly try to retransmit, but it will keep trying and
> sockets can "stall" where recovery doesn't occur or lots of
> retransmissions occur - again, this is dependent on the TCP/IP stack
> and application above it.

We can expect fairly high connection quality when it comes to the radio
network. We're in an area with very good coverage.

> I'm not sure about SMS messaging, but from your post I have a leaning
> towards it fiscally for your application because it sounds like
> you'll get a consistent price-per-message, and consistent cost
> perhaps for a retransmitted message. With TCP, it could vary for all
> the reasons above, especially if you get a bunch of slow or lossy
> connections requiring a high retransmission count.

We have the option to refuse trying to send anything when the connection
quality drops below a certain threshold.

With almost 10k in overhead for a connection, we definately need to
transmit more data per established connection than just one or two
packets, with the pricing scheme we currently have.

Or is it possible to keep a TCP connection alive for many hours (or even
days) without transmitting anything?

....and is the packet size of 1500 impossible to adjust? From what I
understand wrt. ethernet, a computer can adjust the MTU. I have no idea
how GPRS works, but maybe the packet sizes are smaller?

Regards,

Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

On 2006-05-09, Michael Zedeler wrote:

> I'm just happy to see your reply. It is not too late to be useful.

Awesome - this one took a few days too for me to get back to!

> I understand what you write so that we'll probably be transmitting a low
> number of packets each sized at 1500 bytes. What about teardown? Doesn't
> that also cost about three packets? That would total 3 (setup) +
> payloads + 3 teardown = 9000 bytes + x*128 bytes overhead (x being the
> number of payload packets.

I'm confused where the 9KB number is coming from - can you clarify?
The three setup packets are absolutely required, and while not
recommended, you could cheat and not need the four closing packets
(FIN/ACK, FIN/ACK) by tweaking the TCP/IP software to close the
socket after one set of a FIN/ACK, or do the Microsoft way
(*shudder*) and just send a TCP RST (reset) when you're done which
will typically drop the socket on each side, provided the socket
timers are tweaked for that behaviour int he TCP/IP stack.

> With almost 10k in overhead for a connection, we definitely need to
> transmit more data per established connection than just one or two
> packets, with the pricing scheme we currently have.
>
> Or is it possible to keep a TCP connection alive for many hours (or even
> days) without transmitting anything?
>
> ...and is the packet size of 1500 impossible to adjust? From what I
> understand wrt. ethernet, a computer can adjust the MTU. I have no idea
> how GPRS works, but maybe the packet sizes are smaller?

I'm wondering if my over-estimates of connection setup overhead have
skewed your calculations - could you tell me where that 10KB number
comes from and/or share the calculation with me? It is possible to
keep a TCP connection open for hours without sending data - there's
an option you can set in socket programming called SO_KEEPALIVE in
most libraries that will turn on TCP keepalives for sockets created.
This has TCP send a no-payload packet every so often to keep the
connection established. MTU certainly can be adjusted, and TCP
automatically figures out what it needs to do. You can reduce the MTU
to anything you like as long as it's not below a usable size.

/dmfh

----
__| |_ __ / _| |_ ____ __
dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----