Subject: [Tsvwg] Question on Limited Transmit (RFC3042)

From: Reiner Ludwig <[email-masked]>
Date: Tue, 19 Nov 2002 12:29:36 +0100

we are currently investigating ways to improve the performance of 
request/response-style TCP-connections. In this context, we also look into 
the Limited Transmit algorithm.

One "problem" we see is that LT only kicks in if a TCP sender has 
previously unsent data queued for transmission. But, what if the TCP sender 
is application-limited as commonly the case for interactive TCP 
connections? In that case, the TCP sender has no previously unsent data 
queued for transmission.

One idea would be to allow such *application-limited* TCP senders to fast 
retransmit the oldest outstanding segment upon arrival of the first DUPACK. 
(Maybe with the additional condition that no more than 3 segments are 
outstanding at that time. Otherwise, there is still hope that the 3rd 
DUPACK returns.)

This would also follow the packet conservation principle, and would be a 
further step towards making TCP's performance even less dependent on the 
retransmission timer.

Clearly, this approach gives up robustness against packet reordering, but 
*only* in case the TCP sender is application-limited. Thus, the performance 
of that TCP connection shouldn't suffer much from packet reordering, and 
the impact for congestion in the network doesn't seem so large either.

Any thoughts?

///Reiner  

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

---

From: Urtzi Ayesta <[email-masked]>
Date: Tue, 19 Nov 2002 13:43:06 +0100

Hello,

About a month ago we wrote an Internet-Draft discussing how to complement the 
Limited Transmit Algorithm when there is no more unsent data queued. In this 
document we limit ourselves to the case of short-Tcp when losses occur at the 
very end of the transfer. Nevertheless all equally applies to the case when 
no more unsent data is queued (e.g. interactive applications).

Any comments or remarks will be appreciated.

regards,
Urtzi

        Title           : On reducing the number of TimeOuts for short-lived  
                            TCP connections
        Author(s)       : U. Ayesta, K. Avrachenkov
        Filename        : draft-ayesta-to-short-tcp-00.txt
        Pages           : 5
        Date            : 2002-10-21
        
This document shows that short TCP sessions are prone to timeout. In
particular, one single segment loss will provoke TCP to timeout if the
document size is below certain threshold. This document analyzes the
benefit of TCP modifications such as Limited Transmit Algorithm
[RFC3042] and Increasing Initial Window [RFC2414] in the context of
short-lived TCP transfers. However TCP remains vulnerable to the losses
at the very end of the transmission. Therefore we suggest complementary
modifications to Limited Transmit Algorithm to recover effectively from
losses at the end of the TCP transfer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ayesta-to-short-tcp-00.txt

---

From: Mark Allman <[email-masked]>
Date: Tue, 19 Nov 2002 14:42:22 -0500

> One idea would be to allow such *application-limited* TCP senders
> to fast retransmit the oldest outstanding segment upon arrival of
> the first DUPACK.  (Maybe with the additional condition that no
> more than 3 segments are outstanding at that time. Otherwise,
> there is still hope that the 3rd DUPACK returns.)

This was actually part of the original Limited Transmit document.
We termed what you describe Early Retransmit.  That is, if the cwnd
was "small enough" and there was no new data to send then we could
fast retransmit on the first or second duplicate ACK.

As you note this can bust in some situations (due to reordering).
So, we talked about ways to mitigate this (only allow one such
retransmit per connection, one such retransmit per X seconds, etc.).
But, in the final analysis we could not get consensus on this change
and did not want to hold up Limited Transmit waiting for it.

I remain of the opinion that Early Retransmit is a useful idea and
it could certainly be useful.

allman

--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg