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

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 17 Dec 2002 11:58:45 -0600

> 
> We should also be careful to note the stated IAB concern from Sally 
> Floyd that congestion-avoidance needs to be added to VoIP application
> protocols  (e.g. RTP) if VJ-compatible congestion avoidance is not 
> already present in those  protocols. 
 
Clipped from dccp discussion:
http://www1.ietf.org/mail-archive/working-groups/dccp/current/msg00075.html

   > * The original remarks in the IEPREP meeting (diatribe that 
   > could be skipped): 
   > 
   > In the IEPREP meeting, the example that occasioned my remark was
   > that of a best-effort, VoIP connection to Nairobi, with good quality,
   > with reports on the viewgraph of typical packet drop rates of 5-40%.
   > It turned out that the VoIP connection was sending 64Kbps, on a
   > 128Kbps link with many users sharing the link.  The voice quality
   > was good.  My question was about the experience of the TCP connections
   > sharing the link at the time.  My own (strong) view is that a
   > best-effort VoIP connection that sent at 64Kbps in the face of a
   > persistent packet drop rate of 40% would be unacceptable, and should
   > explicitly *NOT* be sanctioned by IETF standards.  Even if it is
   > the case that there is never any congestion in Northern hemisphere
   > Internet backbones and transoceanic links.  And even if there in
   > fact is a "SHOULD" somewhere in one of the RTP drafts about congestion
   > control.
   > 
   > - Sally
   > (writing as in individual)
   > http://www.icir.org/floyd/
   > 

> It is my understanding that work is in-progress on this topic in 
> various IETF Working Groups, so it is likely that VoIP application 
> protocols will be  implementing and deploying VJ-compatible congestion 
> avoidance in future. 

To be precise..It is still in research stage. As of now, We have TFRC for
applications using fixed packet size(ietf-tsvwg-tfrc-05). As per colin,
Voice codecs generally sent packets at constant duration and hence current
TRFC proposal will not be applicable. thats the reason why colin was
skeptical of using dccp for VoIP in ieprep list.  But, as per sally floyd, 
their is a possible submission on TRFR-PS for RTP applications. More details 
from sally floyd's reply in the link mentioned above.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Sally Floyd <[email-masked]>
Date: Tue, 17 Dec 2002 11:43:26 -0800

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

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 23 Dec 2002 12:15:52 -0600

> What is the transport-layer mix? 
> 90% ~ TCP 
> 10% ~ UDP and others 

For a more updated TCP/UDP ratio:
http://ipmon.sprintlabs.com/packstat/viewresult.php?8:protobreakdown:nyc-09.0-021121
compare with the old data from caida collected at AIX exchange.

You can observe 90:10 from a raw  tcpdump data taken from your system too.

The 90:10-tcp:udp is the standard observation.
But, more interesting will be knowing who contributes to the UDP traffic.
Obviously file sharing..
http://ipmon.sprintlabs.com/packstat/viewresult.php?2:appsbreakdown:nyc-02.0-021009

Also, an interesting work will be pumping a good traffic mix across a
congested link (at some IX point) and see, how much UDP  
affects TCP based applications? or a trace driven simulation.
This will give some clue on when to terminate the application-limited flows
to leave way for tcp/tcp-friendly traffic.

btw, you can also see the link utilization and how well provisioned the sprint 
backbones from those pages.

> 
> With a ratio of, say, 80% for TCP and 20% for UDP 

I guess..90/10 is the standard measured one. If your dump data shows 80/20 or
less, we really need to think about ways to protect tcp/tcp-friendly traffic
from UDP traffic (like when to terminate a UDP flow and use of ECN to do
such work.) 

> and packet 
> drop rates of
> 10-40%, would the link be more or less unusable for TCP traffic?
>