TCP for Real-Time services - TCP-IP

This is a discussion on TCP for Real-Time services - TCP-IP ; Hi all, I am trying to understand how a real-time service is supported over TCP. When the application codec work at low rate, TCP sending rate will grow as application data is generated, although ACKs arrive before (I guess). My ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: TCP for Real-Time services

  1. TCP for Real-Time services

    Hi all,

    I am trying to understand how a real-time service is supported over
    TCP. When the application codec work at low rate, TCP sending rate will
    grow as application data is generated, although ACKs arrive before (I
    guess). My concern is when we use a codec with a very high bitrate.
    Then TCP increase its window size in a RTT basis, but what happens when
    TCP throughput is not able to support the codec rate?

    Regards,
    Ricardo


  2. Re: TCP for Real-Time services

    Ricardo wrote:

    > I am trying to understand how a real-time service is supported over
    > TCP.
    > what happens when
    > TCP throughput is not able to support the codec rate?


    If the codec requires throughput that's not available, then something's
    not going to work.

    You can attempt to recognize such a situation, but your application
    cannot fix the problems that cause it (packet loss, limited throughput,
    slow consuming application).

    Common ways of recognizing such a situation include:
    - Application has a large buffer that drains into TCP. Application
    monitors the depth of that buffer. When the buffer depth reaches a
    critical point, the application gives up.
    - Application protocol includes data
    acknowledgement/keepalive/heartbeat mechanisms in addition to those
    offered by TCP. This way the sending application will know that data
    is being delivered to the consuming application.

    /chris


  3. Re: TCP for Real-Time services

    "Ricardo" dixit:

    > Hi all,
    >
    > I am trying to understand how a real-time service is supported over
    > TCP. When the application codec work at low rate, TCP sending rate will
    > grow as application data is generated, although ACKs arrive before (I
    > guess). My concern is when we use a codec with a very high bitrate.
    > Then TCP increase its window size in a RTT basis, but what happens when
    > TCP throughput is not able to support the codec rate?


    Provided your channel is able to cope with it (that is, you don't pretend
    to use a 28K modem for videoconference), TCP will increase its sending rate
    until a bottleneck elsewhere in the network is found. Usually some router
    queue would be overwhelmed and would start to drop or delay packets,
    triggering NACK or keepalive timers. Then, usually, TCP would be expected
    to reduce its window size.

    To fix this potential problem some QoS protocol exist, although I am not
    very knowleadgeable about them.

    Marcos






  4. Re: TCP for Real-Time services

    On Thu, 11 May 2006 02:07:16 -0700, Ricardo wrote:

    > Hi all,
    >
    > I am trying to understand how a real-time service is supported over
    > TCP. When the application codec work at low rate, TCP sending rate will
    > grow as application data is generated, although ACKs arrive before (I
    > guess). My concern is when we use a codec with a very high bitrate.
    > Then TCP increase its window size in a RTT basis, but what happens when
    > TCP throughput is not able to support the codec rate?


    I don't know much about codecs, but many will adapt to less bandwith. The
    results arn't pretty though. In general, you'll want to reserve the
    correct amount of bandwith either through dedicated links, QoS or limiting
    all other traffic. Limiting all other traffic is a hack, but sometimes you
    have no other option. We actually use all of these techniques depending on
    the local situation and local politics to reserver bandwith for
    interactive applications.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  5. Re: TCP for Real-Time services

    On 2006-05-12, Marcos Martinez Sancho wrote:

    > Provided your channel is able to cope with it (that is, you don't pretend
    > to use a 28K modem for videoconference), TCP will increase its sending rate
    > until a bottleneck elsewhere in the network is found. Usually some router
    > queue would be overwhelmed and would start to drop or delay packets,
    > triggering NACK or keepalive timers. Then, usually, TCP would be expected
    > to reduce its window size.


    I'd like to preface my comments by saying this isn't a flame to the
    poster above, but I felt compelled to chime in here to offer a
    different point of view.

    Many, many application developers point to the network's capacity to
    handle traffic as a common cause of congestion or non-delivery of
    packets. Personally, as a troubleshooter often examining application
    performance through packet analysis, I must disagree - the pendulum
    of root cause has moved in the last half-decade from the network back
    towards the application.

    The rise of high-level languages and the business need for rapid
    development has driven the application control of network traffic to
    higher and higher abstraction layers on the hosting computer. This
    creates a lack of both knowledge and control of the traffic. A good
    example of this is a case I run into often where an application with
    real-time requirements written in Java seems to experience excessive
    network latency. The root cause proved that GC (Garbage Collection)
    by the Java engine caused a traffic halt from the application every
    several minutes.

    Networks certainly can and do experience congestion and the Internet
    is no stranger to this, but inside the enterprise a good packet trace
    in controlled conditions gets to the issue quickly and stops the
    finger-pointing rapidly.

    /dmfh

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

  6. Re: TCP for Real-Time services

    On Mon, 15 May 2006 05:24:29 -0400, DMFH wrote:

    [ The network is seldom the problem nowadays ]

    True, so true.

    > Networks certainly can and do experience congestion and the Internet
    > is no stranger to this, but inside the enterprise a good packet trace
    > in controlled conditions gets to the issue quickly and stops the
    > finger-pointing rapidly.


    If only. We just had one and a half year of fingerpointing. We NEED more
    bandwith. Analysis showed the app used a pingpong protocol and
    performance was therefore inherently tied to the RTT. Which is higher over
    a WAN than a LAN. Increasing bandwidth would not and did not increase
    performance. Only a rewrite of the application (or alternatively, move the
    application to a terminal server) can make the performance better.

    Now last week, we migrated one location from 2Mb to 10Mb. Due to a
    configuration error the PVC for this app of 384Kb can now burst to 10Mb
    instead of 2Mb. Needless to say, this did not increase performance one
    bit. We did not correct the error for now. I'll tell them next week that
    they finally had the bandwith they wanted, and show them some nice graphs
    of a mostly empty, peak 200Kb, PVC of 10Mb. Hope they get the point then.

    Other than that I agree completely with your point. I learned some while
    ago that packet traces are often the key to finding why applications
    misbehave.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  7. Re: TCP for Real-Time services

    > but what happens when TCP throughput is not able to support the codec rate?

    You will drop or que segments. :-) I expected you know that already
    though. Where exactly those segments get dropped is another question,
    and the answer is dependent on what is causing the bottleneck.

    If your talking about where the TCP socket is accessed by the
    application, TCP really doesn't do anything differently. The
    application writes to a buffer. When the buffer fills, the application
    either ques or drops segments. TCP does best effort to flow as fast as
    possible, but when it isn't fast enough it is up to the higher layer to
    sort it out.

    Or at least that is my understanding of the situation. I could be
    wrong. This is usenet after all.

    -Matt
    ..


  8. Re: TCP for Real-Time services

    Ricardo wrote:
    >I am trying to understand how a real-time service is supported over
    >TCP. When the application codec work at low rate, TCP sending rate will
    >grow as application data is generated, although ACKs arrive before (I
    >guess). My concern is when we use a codec with a very high bitrate.
    >Then TCP increase its window size in a RTT basis, but what happens when
    >TCP throughput is not able to support the codec rate?


    Buffer starts to fill up, and either something will start to block
    sooner or later or one or both ends detect that the other end is
    falling behind and adjust. IMHO to much depends on the sender and
    receiver to be able to say more than that.

    Make sure both sides is capable of having large enough windows, and
    look at the packet stream to make sure it actually USE those window
    sizes you think you have set :-)

    I think you need to tell us more what the problem is, how much you
    have checked on what is actually going on and what the constraints of
    the problem are.


    OTOH I also have to remark that this sounds like a classical example
    of something that probably should run over UDP instead of TCP, since
    some of the aspects of TCP tends to be problematic for (soft) RT
    services (output stream is stopped if there are any lost packets until
    it has been retransmitted, this is often unaceptable).

    However, using UDP means that one has to either use both TCP and UDP
    and/or reimplement some parts of what TCP provides over UDP. I've
    never used SCTP, but the little I've seen suggest it could solve both
    problems, but using it requires that the hosts (and other equipment!)
    in questions handle it (and SCTP isn't THAT common yet).

    http://www.sctp.org/
    http://tdrwww.exp-math.uni-essen.de/...chung/sctp_fb/

+ Reply to Thread