<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.5730.11" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><BR><BR>
<DIV><SPAN class=gmail_quote>On 2/5/07, <B class=gmail_sendername>Douglas
Leith</B> <doug.leith@nuim.ie> wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>Perhaps I can add my own question to this. The discussion so
far<BR>has mostly centered on whether its possible to detect ack
losses.<BR>But say we could measure these ack congestion/losses - what would
the<BR>right thing be to do ? Should we treat loss of
any packet (ack or<BR>data) as congestion, or just consider loss of data
packets as being<BR>meangingful ?<BR><BR>This isn't as abstract a
question as it might at first seem. Most<BR>delay-based algorithms
use two-way delay and so react to queueing of<BR>acks as well as data
packets. That is, unlike loss based algorithms<BR>they *do* treat
ack and data packets in similar ways for congestion<BR>control
purposes. Is this a good thing or not ?
Doug </DIV>
<DIV> </DIV>
<DIV>
<HR>
</DIV></BLOCKQUOTE></DIV></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>of course it is not good. we had a paper on
performance evaluation of NewReno, Vegas and TCP Westwood+ on ACM CCR 2004
showing that reverse traffic (i.e. ack queuing) shut down forward vegas traffic.
the effect of reverse traffic was also shown for Fast TCP in a paper we had at
pfldnet 06.</FONT></DIV>
<DIV><FONT face=Arial size=2>to conclude, in case of delay based control you
should measure forward delay, rrt is not enough.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>saverio</FONT></DIV></BODY></HTML>