Subject: [Tsvwg] TCP trash-friendliness and TFRC

From: "Andrei Gurtov" <[email-masked]>
Date: Wed, 19 Mar 2003 15:10:08 -0800

Hi,

The TCP rate formulae for TFRC includes only loss rate, RTT (and MSS) as
factors determining the TCP friendly sending rate. Consequently, if a TFRC
flow runs concurrently with a TCP flow over a path with packet reordering,
duplication or delay spikes, TFRC can significantly overshoot TCP. It would
be nice to improve the TCP-friendly rate formulae to reflect reduction of
the TCP rate during these events.

The second thing is that TCP Reno seems to be widely recognized as a
reference rate flow that does not cause congestion collapse under any
circumstances. However, TCP Reno does send a significant amount of
unnecessary data due to (spurious) timeouts and spurious fast retransmits.

We can define TCP trash-friendliness as the amount of unnecessary data sent
by TCP Reno over given network conditions. Since everybody finds TCP Reno
acceptable, other TCPs could implement different features as long as they
remain TCP friendly and trash-friendly.

A first guess about the formulae looks like follows:

t=(Cd*Rd+Cr*Rd+Cs*Rs+Ct*Rt)/w

Where
t - the fraction of unnecessary delivered packets
w - average TCP window (can be computed using rate from TFRC formulae and
RTT)
Rd - rate of "bad"* duplication events
Cd - number of retransmitted segments per duplication event (default 1)
Rr - rate of "bad" reordering events
Cr - number of retransmitted segments per reordering event (default 1)
Rs - rate of "bad" timeouts
Cs - number of retransmitted segments per spurious timeout (default w)
Rt - rate of "good" timeouts (due to several lost packets)
Ct - number of retransmitted segments per good timeout (default w/2)
       (Reno uses go-back-N which retransmits many packets unnecessarily)

*Since not all delay spikes, reordering length or duplication patterns cause
troubles we only account for "bad" cases which do cause retransmissions.

Given this formulae, TCP SACK could for example apply a more aggressive
retransmission timer because its more efficient loss recovery allows to keep
t low.

Furthermore, TCPs detecting spurious timeouts and fast retransmits do not
have to use complicated adaptation schemes for RTO and dupthresh as long as
their t is below Reno's.

Probably, those are completely wild ideas...

Andrei

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

---

From: Mark Handley <[email-masked]>
Date: Wed, 19 Mar 2003 15:34:13 -0800

>the TCP rate during these events.

There is absolutely no good reason why TCP can't cope with significant
re-ordering, and there are several good papers on how to solve this
issue.  The correct solution is to fix TCP.  If TFRC beats up TCP
under these circumstances, they that may provide a good incentive to
fix TCP.

Cheers,
	Mark

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Mar 2003 08:37:48 -0800

Mark Handley wrote:
...
> under these circumstances, they that may provide a good incentive to

Fix TCP because TCP-"friendly" rate control beats up TCP?

With "friends" like that, who needs enemies!

Joe

---

From: Mark Handley <[email-masked]>
Date: Thu, 20 Mar 2003 08:47:26 -0800

>Fix TCP because TCP-"friendly" rate control beats up TCP?

No.  Fix TCP because a decent standards-compliant TCP implementation
that didn't trip over its own showlaces in the face of reordering
would beat up existing TCP implementations.

>With "friends" like that, who needs enemies!

:-)

 - Mark