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

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Nov 2002 18:30:24 -0600 (CST)

Included message from Sally Floyd <[email-masked]>:

>----
>I agree.  I think it needs a document making the worst-case behavior
>quite clear, and arguing why this worst-case example is sufficiently
>unrealistic that it is (or is not) an acceptable risk.
>
>Something like the following:
>
>* Worst-case scenario:  
>- All transfers on this link are from two-packet TCP connections
>(because the web server only has this one two-packet page:).
>- All pairs of packets are reordered in the network.
>- As a result, all connections get the (S)ACK for the second packet before 
>the ACK for the first packet, invoke Early Retransmit, and
>unnecessarily retransmit the first packet.
>- The result is that one-third of the bandwidth on the
>link in question is wasted on unnecessary retransmissions.

While a specific "link" (I assume that you are referring to
the directly connected network segment of one interface) sometimes
matters, but I believe most of the time the re-ordering happens
out in the network.  "Link" does not seem to be a useful info here.
Maybe I misuderstood the meaning of "link" above.  Please correct
me and specify its precise meaning.

TCP only knows about destination addresses.  It does not know
which path a segment actually takes to get to a destination.  If
a connection to a particular destination is short lived and only
has 2 packets to send most of the time, TCP can only infer 
that this destination is not suitable for this kind of "early
retransmit."  But if it is a server talking to many different
clients in many different networks, I don't know how useful this
info is.   TCP cannot even tell if two different IP addresses
belong to the same network since it does not know about network
mask, although intelligent guess can be made.

Limited trasnmit does not require SACK (it actually requires
some more handling when SACK is used).  But does "early retransmit"
require D-SACK to more reliably distinguish duplicate segment?
If so, it will probably limit its usefulness.

>* Argument why this worst-case scenario is an OK risk:
>- There are very few (if any) links where most of the packets
>are from a data-limited connection in where the sender does not
>have a new packet that it wants to send.
>- Thus, even with reordering of all packet pairs, there are very
>few links where this would lead to anywhere close to one-third
>of the link bandwidth being wasted on unnecessary retransmissions.

I had experience that traffic going from one site in a company
I previously worked for to another site had massive re-ordering
problem.  The problem was that there were two dedicated lease
lines between the two sites and the router did load balancing
between them.  But there was no problem to another site because
traffic went through another line.  How can TCP differentiate
these two cases if TCP knows nothing about the path.  Is "link"
above equal to "path?"

>- There are transport-level mechanisms to limit the use of Early
>Retransmit within a single data-limited connection, so that a single
>connection does not repeatedly use Early Retransmit to unnecessarily
>retransmit a packet.

What is the transport-level mechanism to limit the use of
"early retransmit?"  Assuming the simplest policy of using D-SACK
that after TCP finds that "early retransmit" causes duplicate
segment to be sent, it stops doing that.  It seems to me that
several months later, a question will be asked why the "first
strike" policy, why not "second or third strike?"  This probably
means that a dynamic policy is required.  Is this complicated
justified?  Maybe I have missed something here, please elaborate
the above idea.

>----

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

---

From: Sally Floyd <[email-masked]>
Date: Wed, 27 Nov 2002 11:07:04 -0800

Marco, Michela and Claudio -

>    as you might remember, a few months ago we submitted a draft that
>addressed, trying to alleviate it, the RTO penalty for TCP
>connections in the "small window" regime.
>
>It was available as "draft-mellia-tsvwg-tcp-smartframing-00.txt"

Looking back over my email response of January 16 on the mailing list,
I said that "I don't buy it that four small packets presents the same
load to the network as one larger packet."  That would still be my own
personal opinion.  But I would agree that someone evaluating Early 
Retransmit should also compare it against other proposed mechanisms
for avoiding a retransmit timeout when a dup ack arrives and the
sender has no new data to send.

- Sally