IP overhead? - Network

This is a discussion on IP overhead? - Network ; 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? ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: IP overhead?

  1. IP overhead?

    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.

    It is not crucial that I get exact estimates, but it would be nice to
    know how much data is transferred during setup, teardown and then a
    relative overhead on the payload.

    Hope someone out there have theese figures handy.

    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

  2. Re: IP overhead?

    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 @ / _` | ' \| _| ' \ _ / _\ \ /
    \__,_|_|_|_|_| |_||_| (_) \__/_\_\
    ----

  3. Re: IP overhead?

    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

  4. Re: IP overhead?

    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 @ / _` | ' \| _| ' \ _ / _\ \ /
    \__,_|_|_|_|_| |_||_| (_) \__/_\_\
    ----

+ Reply to Thread