Subject: RE: [Ieprep] Summary of ieprep work and VoIP--Take 2

From: "Nguyen, An" <[email-masked]>
Date: Mon, 23 Dec 2002 08:57:51 -0500

Sally,

I am just curious. What is the transport-layer mix? 
90% ~ TCP 
10% ~ UDP and others 

With a ratio of, say, 80% for TCP and 20% for UDP and packet drop rates of
10-40%, would the link be more or less unusable for TCP traffic?

Thanks,

An

-----Original Message-----
From: Sally Floyd [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 2:43 PM
To: King, Kimberly S.
Cc: Ieprep (E-mail); 'RJ Atkinson'
Subject: Re: [Ieprep] Summary of ieprep work and VoIP--Take 2 

Kimberly -

>"If other non-VoIP traffic is also carried, then there is a 
>tradeoff to make between the performance of voice and non-voice 
>applications.  For example, enough VoIP on a congested link 
>(e.g., 10-40% packet drop rates) can be sufficient to make the
>link essentially unusable for TCP traffic. "

So I went back and read the email that this came from.

I think I will steer clear of a discussion of what is "usable" or
"unusable" for TCP traffic, as I would agree that that is not really
the point.  (I don't know if the word "unusable" originally came
from me or not...)

With 40% packet drop rates, TCP traffic is undergoing frequent
retransmit timeouts (because when the congestion window is one
packet, and that packet is dropped, a retransmit timeout is the
only recovery mechanism).  With the recommended minimum retransmit
timeout value of one second, and the occasional exponential backoff
of the retransmit timer, a TCP connection is getting through less
than one packet per second.  And if there were multiple congested
routers along the path, then potentially-useful bandwidth was wasted
carrying packets that would only be dropped downstream.

With 10% packet drop rates, a TCP connection could conceivably be
seeing a throughout of several packets per RTT (e.g., if the TCP
implementation is using Limited Transmit, and thereby manages to
avoid too many retransmit timeouts).  This is not too bad.  Of
course, there still are those connections that have long initial
delays (several seconds) retransmitting their dropped SYN packets.

Since everyone agrees on this:

>- Letting non-congestion-avoiding traffic crowd out congestion-avoiding
>   traffic is a very bad thing from an architectural or system engineering
>   perspective.
>- VoIP or any other application that doesn't include congestion-avoidance
>   needs to be modified to implement and use congestion-avoidance.

that seems to me to be what really matters.

(The TCP traffic *could* be carrying email or instant messaging
traffic or web traffic that is just as important for the emergency
communications as the VoIP traffic, it would seem to me...)

(And since this was just about an email message, the original email
message doesn't even need to be revised and resubmitted...)

- Sally

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Sun, 29 Dec 2002 02:12:24 +0000

> With a ratio of, say, 80% for TCP and 20% for UDP and packet drop rates
> of 10-40%, would the link be more or less unusable for TCP traffic?

one needs to be careful in how things are phrased.  the mix of
protocols, and in particular the amount of TCP, gives an indication of
that portion of traffic that will automatically attempt to backoff and
avoid congestion (ie, TCP) versus the traffic that is not expected to
backoff (eg, UDP).  so whether the ratio is 90:10 or 50:50 is moot with
respect to the "usability" of TCP traffic.  the key number in the
equation is the *sustained* level of packet loss.

also, the ability of the TCP flow to operate effectively over high loss
(approaching 40%) is dependent on the implementation of an application
-- most commonly the buffer space it requires.  Telnet (ie, sending 1 or
two bytes of app data) is not an application that consumes a lot of
buffer space, hence it can generally operate well in the presence of
high packet loss sustained over long periods.  On the other hand, as an
example, there is a vendor that terminates a TCP connection when its
buffers overflow because it can't forward BGP tables to other BGP
speakers due to loss (less than 40%) sustained over a long period.

ie, one needs to add qualifying statements about loss and TCP.

-ken