Subject: [Tsvwg] Dealing with Spurious Retransmits in TCP

From: Reiner Ludwig <[email-masked]>
Date: Mon, 10 Mar 2003 10:53:16 +0100

[I have cc:ed [email-masked], but please reply only to 
[email-masked] to avoid double postings.]

What about the following rule for those TCPs that are enhanced to detect 
spurious retransmits?

     Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount
     of spuriously retransmitted data) when a spurious retransmit has been
     detected.

The logic would be to say that since the TCP sender has used more than its 
fair share of bandwidth in the past (due to the spurious retransmit), it 
has to pay back for that once the spurious retransmit has been detected.

With that rule, the policies for adapting RTO and DUPTHRESH would become 
less crucial.

Moreover, a TCP sender for interactive applications (assuming that this 
implies that response time is more important than throughput) may then have 
the freedom to use a non-standard retransmission timer (more optimistic; 
not to say more aggressive), and Early Retransmit without concerns.

Taking this a step further, one could argue that as long as the TCP sender 
uses no more than its fair share of bandwidth, it is free to send what it 
wants. For example, everytime an acceptable ACK arrives, and the TCP sender 
does not have new data available, it may retransmit from the queue of 
unacked data.
RTP/UDP-based streams are also allowed to add redundancy in the form of FEC 
and retransmissions when the source rate is lower than the available 
bandwidth, or to trade some of their throughput and responsiveness for an 
increased reliability.
So, couldn't TCP also trade unused throughput for an increased 
responsiveness by adding redundancy in the form of sending potentially 
spurious retransmits?

///Reiner 

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

---

From: Mark Allman <[email-masked]>
Date: Mon, 10 Mar 2003 09:31:58 -0500

> Taking this a step further, one could argue that as long as the
> TCP sender uses no more than its fair share of bandwidth, it is
> free to send what it wants.
>
> [...]
> 
> responsiveness by adding redundancy in the form of sending
> potentially spurious retransmits?

This seems somewhat dicey to me.  

We took some measurements a couple of years ago here that showed
about 60% of the TCP connections (in and out) of NASA GRC contained
only a single data packet.  That might still hold or be a little
different, but I doubt it's that far fetched today.  So, using your
notion from above and RFC3390 we could send the same packet 4 times
-- which hopefully ensures that one of those packets arrives.
Contrast that to sending the one packet and retransmitting as
necessary.  If you take a high loss rate of like 10% then one out of
ten connections will need a retransmit (& so we'll send 11 data
packets to deliver 10).  In the case of sending redundant data
sketched above we would send 40 packets to deliver 10.

You can penalize folks a little bit for this bad behavior.  But,
that doesn't help the above case where a connection spins up and
down so fast that no penalty is really meaningful.

Now all of the above back-of-the-envelope conjecture might not be
exactly right.  But, the point is that using your notion could open
the door to polluting the network with a whole bunch of data that
potentially gets in the way without accomplishing any useful work.
And, I wonder if there are cases where performance would actually
decrease (when lots and lots of people are firing lots and lots of
redundant data into the network to try to improve their
performance).

allman

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

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 10 Mar 2003 07:00:40 -0800 (PST)

Mark and I have been having a private conversation on a related
topic, so when I read 

> sketched above we would send 40 packets to deliver 10.

and then, a little later on,

> redundant data into the network to try to improve their

I'm wondering why we're thinking abut TCP at all for these
applications - or is it just too stupid to imagine another
meaningful transport? Because in addition to the problem Mark is
identifying, we also sent something like eight packets in order
to send one packet with data.

An aside - any clue what application we're talking about? I
immediately started thinking about HTTP/1.0 and/or "Connection:
close", but you should have seen at least one packet in each
direction.

Backing up slightly, I can imagine that if Mark was looking at
HTTP/1.0 connections in his previous work, the percentage really
is probably different today (with much wider HTTP/1.1 deployment
and use), but how different is it?

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 11 Mar 2003 11:25:48 +0100

Hi Mark,

what you describe is not quite what I meant. Let me try again ...

I'm suggesting that as long as the TCP sender preserves 'packet 
conservation' *and* uses the 'ACK clock' to clock out transmissions, it 
should be the TCP sender's decision of what it sends. In particular, this 
means that also the mentioned Potentially Spurious Retransmits (PSRs) may 
only be clocked out by returning ACKs.

That should take care of one of your concern:
     "And, I wonder if there are cases where performance would actually
     decrease (when lots and lots of people are firing lots and lots of
     redundant data into the network to try to improve their
     performance)."
I.e., if the TCP sender has only 500 bytes to send and uses RFC3390, it 
should *not* be allowed to send 4 back-to-back copies of the same segment; 
only one segment since PSRs may only be clocked out by returning ACKs.

Still, I would like to revise the rule I suggested:
     Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount
     of spuriously retransmitted data) when a spurious *timeout* has been
     detected.
This is, because only in the case of a spurious timeout has the TCP sender 
used more than its fair share of bandwidth in the past (due to the spurious 
retransmit). In the case of a spurious fast retransmit, the TCP sender has 
actually *not* violated 'packet conservation' in the past.

Coming back to your point using an example that should be equivalent to the 
example you gave (short lived TCP connections). Let's assume MSS = 500 
bytes and the TCP sender has 2000 bytes to send. Per RFC3390, it can send 
the 4 segments in the first RTT back-to-back. With the approach I 
suggested, the ACK for segment 1 would clock out a PSR of segment 2, the 
ACK for segment 2 would clock out a PSR of segment 3, etc.

Assuming the TCP sender didn't get any loss/congestion indication, it would 
end up sending 7 segments (3500 bytes) instead of only 4 segments (2000 
bytes). So what? The TCP sender didn't use more than its fair share of 
bandwidth.

I'm not totally familiar with all the stream encodings that are being 
defined for RTP, but I wouldn't be surprised at all if some of those codecs 
added FEC with a ratio of 3500/2000. And for RTP streams we are saying: "as 
long as the entire RTP stream behaves TCP-friendly, we are fine."

Something is not right here. We are being more strict to TCP than to the 
non-TCPs. That's not TCP-friendly! ;-)

Maybe, I'm missing something essential here ... but my current view is that 
the approach I suggested should at least be OK as an option that the 
application could set (or the user if it has to pay per byte for her/his 
access link).

///Reiner

---

From: "Injong Rhee" <[email-masked]>
Date: Mon, 10 Mar 2003 11:40:56 -0500

I agree with Reiner. The main problem lies in unnecessary coupling of
recovery and congestion control in TCP. I view CC is an independent from
recovery. Whether it can transmit spurious retransmission or simply do
no-op, it should left to the application or other layer decision.
Therefore, CC must tell the current rate (or window size) that the data
(including retransmission) must be sent at and the recovery layer
decides on whether it should retransmit, forward-error correction or
other data packets. 

Injong Rhee
Computer Science Dept
North Carolina State Univ.
[email-masked]
http://www.csc.ncsu.edu/faculty/rhee

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reiner Ludwig
Sent: Monday, March 10, 2003 4:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: [e2e] Dealing with Spurious Retransmits in TCP

spurious retransmits?

     Those TCPs MUST reduce their cwnd by MSS (alternatively by the
amount
     of spuriously retransmitted data) when a spurious retransmit has
been
     detected.

The logic would be to say that since the TCP sender has used more than
its 
fair share of bandwidth in the past (due to the spurious retransmit), it

less crucial.

Moreover, a TCP sender for interactive applications (assuming that this 
implies that response time is more important than throughput) may then
have 
the freedom to use a non-standard retransmission timer (more optimistic;

Taking this a step further, one could argue that as long as the TCP
sender 
uses no more than its fair share of bandwidth, it is free to send what
it 
wants. For example, everytime an acceptable ACK arrives, and the TCP
sender 
does not have new data available, it may retransmit from the queue of 
unacked data.
RTP/UDP-based streams are also allowed to add redundancy in the form of
FEC 
and retransmissions when the source rate is lower than the available 
bandwidth, or to trade some of their throughput and responsiveness for
an 
increased reliability.
So, couldn't TCP also trade unused throughput for an increased 
responsiveness by adding redundancy in the form of sending potentially 
spurious retransmits?

///Reiner

---

From: Ibrahim Matta <[email-masked]>
Date: Mon, 10 Mar 2003 12:21:13 -0500

Yes, this is the *well-known* problem of coupling
between error control and congestion control
in window-based schemes. Rate-based schemes
naturally decouple the two - see Keshav's textbook
for example.

ibrahim

--
Ibrahim Matta       Dept of Comp Sci, 111 Cummington St, MCS-271
[email-masked]     Assistant Prof, Boston Univ., Boston, MA 02215
Tel: (617)358-1062, Fax: (617)353-6457, URL: www.cs.bu.edu/fac/matta/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Allman <[email-masked]>
Date: Tue, 11 Mar 2003 13:02:39 -0500

> what you describe is not quite what I meant. Let me try again ...

OK.  But, you constructed one case where we can still send a bunch
of redundant segments into the network without indication that they
were lost -- and, even given the rules you sketch I can come up with
other cases, I think.

> Coming back to your point using an example that should be
> equivalent to the example you gave (short lived TCP
> connections). Let's assume MSS = 500 bytes and the TCP sender has
> 2000 bytes to send. Per RFC3390, it can send the 4 segments in the
> first RTT back-to-back. With the approach I suggested, the ACK for
> segment 1 would clock out a PSR of segment 2, the ACK for segment
> 2 would clock out a PSR of segment 3, etc.
> 
> Assuming the TCP sender didn't get any loss/congestion indication,
> it would end up sending 7 segments (3500 bytes) instead of only 4
> segments (2000 bytes). So what? The TCP sender didn't use more
> than its fair share of bandwidth.

Two things jump to mind...

  * Sure, you are sending at your "fair share" rate-wise.  But, if
    we take a wider view we're sending extra stuff which uses
    network resources and we are essentially spinning our wheels.
    While this practice might help our connection (sometimes) it
    also uses resources that other connections could use to
    accomplish useful work (which we are not in most cases).

  * The reason you would need to send such retransmits would be
    because they were lost because the network is congested (using
    the standard TCP assumption).  So, what is the justification
    here?  "Just in case we're congested I'll throw some extra data
    into the network."  Seems like throwing gas on the fire to me.

> I'm not totally familiar with all the stream encodings that are
> being defined for RTP, but I wouldn't be surprised at all if some
> of those codecs added FEC with a ratio of 3500/2000. And for RTP
> streams we are saying: "as long as the entire RTP stream behaves
> TCP-friendly, we are fine."
> 
> Something is not right here. We are being more strict to TCP than
> to the non-TCPs. That's not TCP-friendly! ;-)

I will likewise plead ignorance here.  But, I think one difference
is that the RTP stuff is not reliable and so FEC is the only way to
protect the bits.  That is just conjecture.  And, FEC that blows up
the size of the data by a factor of ~2 (which I think is the upper
bound of extra stuff you could dump into the network given the
scheme you sketched) seems pretty egregious to me (just from
thinking about the sorts of things folk around here talk about for
satellite channels).  (Although, that might be quite different from
what gets applied in application-land.)

Maybe someone more informed could clue us both in!

allman

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 11 Mar 2003 21:34:01 +0100

I know, this PSR (sending Potentially Spurious Retransmit without any clue 
of a loss indication) option for TCP is probably the extreme case of 
maximum redundancy. And I see your points why this might not be so popular. 
Independent of whether that would ever fly, I feel (and that's the point I 
want to make) that we are way too strict to TCP; at least much stricter 
than we are with RTP/UDP-based streams. And that's not fair ;-(

The amount of useful data sent by the current TCP should be pretty close to 
100 percent. The amount of useful data sent by some RTP/UDPs (even if they 
are TCP-friendly) should for certain content encodings be << 100 percent. 
So, I think we should relax a little when it comes to proposals like Early 
Retransmit, and also allow TCP a bit more redundancy (within the bounds of 
packet conservation and the TCP congestion control principles).

Loping back to the Eifel response and alternative schemes, I think that ...

- a spurious timeout is harmful
This is because the resulting spurious retransmit breaks packet 
conservation. One way to address this is to REQUIRE the rule I suggested 
earlier for those TCPs that are enhanced to detect spurious timeouts:
     Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount
     of spuriously retransmitted data) when a spurious timeout has been
     detected.
However, for those TCPs that followed that rule, the retransmission timer 
becomes less crucial. Those TCPs should be free to use whatever 
retransmission timer the implementers choose to use. They MAY use RFC2988, 
but there should be no more IETF restriction that they MUST use RFC2988 or 
any successor. Likewise, (if that rule is used) the resonsibility of how 
the retransmission timer is adapted in response to a detected spurious 
timeout should lie entirely with the implementor, i.e., the TSVWG should at 
most suggest what an implementor MAY do to adapt the retransmission timer.

- a spurious fast retransmit is *not* harmful
This is because the resulting spurious retransmit does *not* break packet 
conservation. Following the same line of argument as above, I would say 
that the resonsibility of how DUPTHRESH is set initially or how it is 
adapted in response to a detected spurious fast retransmit should lie 
entirely with the implementor (except that cwnd MUST be cut in half for a 
DUPACK-based congestion indication), i.e., the TSVWG should at most suggest 
what an implementor MAY do to initialize or adapt the DUPTHRESH (as long as 
DUPTHRESH <= FlightSizeInMSS, I guess). Furthermore, the Early Retransmit 
algorithm would become a totally OK thing to do. Implementors MAY simply 
use it (as long as packet conservation and the TCP congestion control 
principles are preserved).

If that view found consensus in the TSVWG, the problem of how to respond to 
a detected spurious retransmit (spurious timeout or spurious fast 
retransmit) would be reduced to the problem of how to reverse the 
congestion control state.

///Reiner

---

From: Rick Jones <[email-masked]>
Date: Tue, 11 Mar 2003 13:04:17 -0800

Reiner Ludwig wrote:
> The amount of useful data sent by the current TCP should be pretty
> close to 100 percent. The amount of useful data sent by some RTP/UDPs
> (even if they are TCP-friendly) should for certain content encodings
> be << 100 percent. So, I think we should relax a little when it comes
> to proposals like Early Retransmit, and also allow TCP a bit more
> redundancy (within the bounds of packet conservation and the TCP
> congestion control principles).

Is there a pointer to the ratios of TCP to RTP/UDP traffic for the
present and near future?

rick jones
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Urtzi Ayesta <[email-masked]>
Date: Tue, 11 Mar 2003 22:22:03 +0100

>Is there a pointer to the ratios of TCP to RTP/UDP traffic for the
you might want to take a look to these papers:

C. Fraleigh, S. Moon, B. Lyles, C. Cotton, M. Khan, D. Moll, R. Rockell, T. Seely, C. Diot,. "Packet-level
Traffic Measurement from the Sprint IP Backbone" <ftp://ftp.sprintlabs.com/diot/ipmon-ieeenetworks-2003.pdf>. To be published in IEEE Network Magazine. 2003

Kevin Thompson, Gregory J. Miller, and Rick Wilder. "Wide-area
Internet traffic patterns and characteristics". IEEE Network, 11(6),
November 1997.

urtzi

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 12 Mar 2003 11:40:56 -0600

On 3/11/03, Reiner Ludwig wrote:

>I know, this PSR (sending Potentially Spurious Retransmit
>without any clue of a loss indication) option for TCP is
>probably the extreme case of maximum redundancy. And I see
>your points why this might not be so popular. Independent
>of whether that would ever fly, I feel (and that's the
>point I want to make) that we are way too strict to TCP;
>at least much stricter than we are with RTP/UDP-based
>streams. And that's not fair ;-(

There are at least two signifigant differences.

First, the retransmission policy is being applied by the ULP
itself. While there is no way to enforce this, typically the
redundant packets are not selected at random. They represent
critical data which will have a disproportionate impact if
lost. For example, an MPEG Stream can more easily tolerate
the loss of P and B frames than I frames.

The retransmission policy may be limited to critical data
and only in response to a retransmit request. In these
scenarios the ULP is prioritizing retransmission based
upon how critical the data is. When faced with network
congestion the ULP responds by dropping less critical
data messages, either on retransmission or entirely.

PSR adds traffic just in case there may be congestion,
and does so at the transport level without any knowledge
of the relative importance of the data to the ULP.

I'm not judging whether or not there are conditions where
this might be valuable, merely that it is far beyond what
RTP/UDP applications do the network.

A second reason some RTP/UDP applications send redundant
packets even with an explicit NACK is that they are laregly
one-way protocols. There are no routine reverse-flow acks.
This may be because the return path is limited in bandwidth,
has a very long round-trip time, or the forward path is
multicast.

In any event, with every RTP/UDP application I am aware of,
any redundant forward packets are minor compared to the
network savings of omitting reverse path aks.

Additionally, I suspect the trend for these applications
will be to encourage their migration to PR-SCTP or DCP
to encourage more uniform congestion control. RTP/UDP
applications apply rate based control, but do so on
their own without central control. This is admittedly
unfair, and should be phased out someday.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Sun, 16 Mar 2003 19:39:27 +0100

>network savings of omitting reverse path aks.

But as we move current RTP/UDP unicast applications to RTP/DCCP, we will 
have ACK traffic of probably the same order as in the case of TCP.

///Reiner