Subject: Re: New congestion control text in RTP spec

From: Thomas Marshall Eubanks <[email-masked]>
Date: Fri, 04 Aug 2000 19:45:33 -0400

Dear Stephen;

Stephen Casner wrote:

> To the AVT working group:
>
> I'd like to call your attention, for both those who are here at IETF
> and those who are not, to the new sections on congestion control that
> were added to the recent revisions of the RTP spec and profile drafts
> as a result of the discussion at the last IETF:
>
>     draft-ietf-avt-rtp-new-08.txt / .ps
>     draft-ietf-avt-profile-new-09.txt / .ps
>

I cannot find the .ps version of the profile, either on the working group charter
or at the ftp site.

>
> In the RTP spec, the congestion control discussion is in a new Section
> 10, with references in Sections 6 and 13.  It simply establishes the
> requirement for congestion control in RTP, and defers definition of
> any specific behaviors to profiles because they are context-specific.
>
> In the profile, a new "Congestion" item was added in Section 2 using
> the text that Mark Handley provided in response to my request at the
> last IETF meeting.  Again, the requirements are described only in
> general terms because specific algorithms have not been devised yet
> for multicast congestion control.
>
> ---> Is this text in both documents appropriate and sufficient?
>
>                                                         -- Steve

The profile draft states :

             If best-effort service is being used, RTP receivers SHOULD
             monitor packet loss to ensure that the packet loss rate is
             within acceptable parameters. Packet loss is considered
             acceptable if a TCP flow across the same network path and
             experiencing the same network conditions would achieve an
             average throughput that is not less the RTP flow is
             achieving.

I think that this is over-simplistic, and, if really followed, would cause UDP traffic to
tend to zero in the presence of TCP traffic.

We have been running UDP tests from DC to LA across several AS's.
In our UDP streaming tests, network "congestion" is generally actually
UDP versus TCP "contention".

In cross country transmission tests, I rarely see as much as 2% packet loss when the end user is
ONLY running a UDP session, and generally the loss is << 1%. However,
if you are receiving a audio UDP stream over a narrow pipe, such as a DSL or ISDN
line, and start up a TCP connection, such as a ftp file download,
you will experience packet loss as the TCP slow start and the UDP fight it out.
This is true even though the MEAN TCP and UDP throughput is fairly
reasonable. The jitter will also increase, as the following example makes clear :

Suppose you are sending 90 kbps MP3  as UDP over a 128 kbps ISDN line.
Each MP3 packet takes about 19 msec to transmit, and they are sent every 26 msec or so,
leaving a 7 msec "hole" for other data. Suppose that you start an ftp session with 1500 byte packets
(the most common size on the network, due to Ethernet restrictions). This will take
about 100 msec to put through the pipe. So, even if no packets are lost, sending one
TCP packet will delay about 3 or 4 UDP MP3 packets, causing considerable jitter.

Under slow start, the TCP session will send one such packet, then two, etc., until there
is packet loss. Given the size of these packets, when this happens (in this example)
several MP3 packets  will be lost in a row. I would fear that any simple minded
congestion monitoring would then conclude that there was congestion, and
ramp down the UDP. If the TCP was on-going, this process would repeat until the
UDP gave up. Two TCP connections with the same parameters would, both in
theory and in our tests, perform much better, as both would tend to average usage
of a little less than 1/2 the pipe bandwidth.

In addition, how would you determine what a TCP flow "would achieve"
in a real-world multicast situation, where you cannot run such a flow, is very unclear, at least to me.

(RED probably helps a lot for true network congestion in the backbone, but our tests indicate that there is
very little buffer available for a typical ISDN last hop router, of order 1 or 2 TCP packets,
so it may not be so good for last-hop contention problems. This is still unclear to me.)

I would therefore change the profile to read :

"If best-effort service is being used, RTP receivers SHOULD
monitor packet loss to ensure that the packet loss rate is
within acceptable parameters. Packet loss is considered
acceptable for a receiver if the RTP flow to that receiver achieves an
average throughput that is not less than 90% of the nominal bandwidth for that  RTP flow."

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]     [email-masked]

http://www.on-the-i.com http://www.buzzwaves.com

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Sun, 6 Aug 2000 08:56:12 +0200

> [...] several MP3 packets  will be lost in a row. I would fear that any
> simple minded
> ramp down the UDP.

Then don't use a simple minded congestion monitoring scheme!
Schemes like TFRC have been designed to compete fairly with TCP.
(However, in your example, where you send 90 kbit/s RTP over a 128 kbit/s
link, TFRC would still try to regulate that down to around 64 kbit/s if you
have a bulk data TCP connection going at the same time.)

> bandwidth for that  RTP flow."

Now that would be a "simple minded congestion monitoring" scheme, indeed!

Gruesse, Carsten

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Tue, 15 Aug 2000 12:34:58 -0400

Steve,

             "If best-effort service is being used, RTP receivers SHOULD
             monitor packet loss to ensure that the packet loss rate is
             within acceptable parameters. Packet loss is considered
             acceptable if a TCP flow across the same network path and
             experiencing the same network conditions would achieve an
             average throughput that is not less the RTP flow is
             achieving. This condition can be satisfied by implementing
             congestion control mechanisms to adapt the transmission
             rate (or the number of layers subscribed for a layered
             multicast session), or by arranging for a receiver to leave
             the session if the loss rate is unacceptably high."

I have a few questions about the above quotation from the profile document.
First, in practice, how does an RTP end-point determine the "average
throughput" of a TCP flow "across the same network path and experiencing the
same network conditions"? If you (authors) have a particular reference for
this in your mind, shouldn't it be at least specified here? Second, what is
the time period over which this "average" is to be computed?

Thanks.

M. Reha Civanlar

---

From: Mark Handley <[email-masked]>
Date: Tue, 15 Aug 2000 10:20:24 -0700

>the time period over which this "average" is to be computed?

Given that I think this was a paragraph that I wrote, perhaps I should
respond.  

 - The text represented what I thought was the consensus of people in
   the meeting room in Adelaide.  Ie, that it's the job of the RTP
   spec to say that best-effort applications should do congestion
   control, but not the job of the RTP spec to give the precise
   details of how this congestion control should be done.  This is the
   normal IETF way of doing things - decouple functionality as far as
   possible.

 - The average should be computed over a sufficiently long time period
   to be useful to the application and a sufficiently short period to
   respond to real changes in network congestion and prevent
   congestion collapse or starvation of competing TCP traffic.  Only
   experience of deploying new congestion control techniques in the
   real world can tell us what these bounds are (although simulations
   give us a rough idea).  Again this isn't RTP-specific so
   shouldn't be in the RTP spec.
 
 - I was thinking of TFRC (http://www.aciri.org/tfrc) when I wrote the
   text.  But I don't think the IETF wants to *mandate* this particular
   scheme for RTP congestion control.  

BTW, we do intend to write up an internet-draft on TFRC sometime soon.

Cheers,
	Mark