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

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

"Ricardo" <riqui29@yahoo.es> 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

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.

On 2006-05-12, Marcos Martinez Sancho <noemail@noemail.be> 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 @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----

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.

> 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
..

Ricardo <riqui29@yahoo.es> 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/