Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.

From: Mark Allman <[email-masked]>
Date: Sat, 12 Jan 2002 17:37:59 -0500

> If you look at it another way, there is no decision to be made
> now, it is the "standard" practise.  

Right.

> Look at the example we are discussing now, spurious timeout.  If a
> stack detects a spurious timeout for sure, it keeps the states
> prior to the timeout and stops immediately sending duplicate
> packets out.  If it is not sure, the standard practise of slow
> start will take place.  So if the detection is very good, you
> don't need to worry about that.

I don't need to worry about what?  If we know we spuriously
retransmitted something we know we added a packet to the network
that accomplished no work (yet used resources).

> Looking at it from your point, I believe you are more worried
> about things like making a correct decision to trigger a fast
> retransmit, as what you are working on.

No, I am worried about both RTOs and fast retransmits, actually.  I
have *studied* only the fast retransmit case.  But, both cases need
solved. 

> But IMHO, regardless of whether there is a machanism to revert
> back to the previous state, there is an incentive (a real
> incentive this time (-:) not to unnecessarily fast retransmit.  In
> the extreme case you mentioned, it means that the real throughput,
> even if TCP never slows down, can be at best 2/3 of the max.  This
> is probably not acceptable to most people...

I'll get a copy of our paper posted early next week.  But, we have
an example in the paper that compares two TCPs:

1.  a standard SACK-based version of TCP
2.  a version of TCP that can detect spurios fast retransmits and
    undo the bogus CC state changes (but, takes no action to prevent
    further needless retransmits)

This is done in a network with varying amounts of reordering -- so
needless retransmits do happen.

What we see is that (2) gets throughput that is almost as good as
(1) does when there is no reordering (i.e., no needless
retransmits).  There is about a 1% performance hit if we can detect
spurious retransmits and undo the CC changes.  On the other hand, if
you look at the number of needless packets sent variant (2) sends
about 6 times as many as standard SACK (variant (1)).

So, while there are cases when I think you are right that there is
an incentive because needless retransmits throw away *your*
bandwidth and that can have a big impact, I also think there are
cases when this incentive is negligible.

And, I think this is a problem.  I like the performance gain from
detecting spurious retransmits.  But, I wouldn't like to see people
pile in a lot of unnecessary packets into the network.

> To me, the key is if we are really making TCP more aggressive if,
> for example, the spurious timeout detection mechanism is
> "extremely (need to quantify it) good."  I think it is not.

I do not understand this comment.  Eifel is pretty robust, it seems
to me.  But, regardless I haven't heard of any failure cases --
i.e., when it says there was a spurous timeout and there was not.
Are there some?

> For the topic we are discussing, I think it is safe to revert
> things back after a timeout if TCP can know for sure the timeout
> is spurious.

And, just so we're clear my own opinion is that reverting CC state
is not safe unless some action is taken such that the chance for
spurious retransmit (RTO or FR) in the future is reduced.

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

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

---

From: Pasi Sarolahti <[email-masked]>
Date: Sun, 13 Jan 2002 14:30:45 +0200

Hello,

May I comment one point of your discussion?

> i.e., when it says there was a spurous timeout and there was not.

I have been running into one suspicious case. If there is a "link outage" 
when both data and ack packets get dropped in the same window, and timestamps 
as specified in RFC 1323 are used as the retransmission indicator, Eifel can 
make a wrong conclusion. This is a simplified example of my problem I sent to 
Reiner Ludwig and Andrei Gurtov a week ago:

1. Sender sends a window of data segments 11-20 <timestamp 101-110> as
clocked by incoming acks
2. Data segment 15 is dropped
3. Receiver acknowledges 11-14 (tsecr 101-104) plus sends 5 dupacks (tsecr
104 in all of those), but ACK segment(s) for 13-14 and the dupacks are
dropped
4. RTO expires at the sender, sender retransmits data segment 13 <tstamp
120>
5. Receiver acknowledges segment 14. Since this is dupack, tsecr is still
104. However, at the sender this appears as a new ack. Because 104 < 120,
the sender declares the retransmission spurious.

The basic Eifel would undo the congestion control parameters and continue 
transmitting new data, right? Eifel detection is basically correct, since the 
retransmission triggered by RTO is unnecessarily made, but undoing the window 
and continuing with new, unsent data is a wrong action to take, since 
data segment was lost. In my tests the RTO that occurred during link outage 
was followed by a backed off RTO. First the sender did fast retransmit due to 
duplicate ACKs triggered by the new segments sent after Eifel detection. cwnd 
was reduced, and there were not enough packets in the pipe to keep the fast 
recovery running (due to the recent link outage, which actually dropped more 
than one data segments). SACK and limited transmit were in use.

As Andrei pointed out to me, many implementations use a different (fixed?) 
version of timestamps which avoid this problem. The issue about timestamp 
specification has been discussed under the pilc list lately, although in a 
slightly different context.

- - Pasi

- -- 
http://www.cs.helsinki.fi/u/sarolaht

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 Jan 2002 18:05:17 -0800 (PST)

> that accomplished no work (yet used resources).

You don't need to worry about TCP sending too many unnecessary
segments out because it is being too aggressive if the detection
mechanism is very good.

> about 6 times as many as standard SACK (variant (1)).

First, I guess the number 6 is only about the number of needless
segments.  Please correct me if I am wrong.  What is the overall ratio
of the needless segments to the number of segments in total?  I am not
suggesting that if the ratio is low, it is perfectly fine.  I just want
to point out that the 600% may seem a big number to people but the
effect of it may not be as big as it seems.  Again, if routers are
equipped to "punish" overly aggressive TCP, if the ratio of needless
segments to total segments is high, the aggressive TCP will back off.

Again, please don't get me wrong, I am not saying that we should not
look at the problems you gave above.  I just want to point out that
it may not be a problem as big as people seem to suggest.  And I
believe we do have a big problem in wireless world now, spurious

> pile in a lot of unnecessary packets into the network.

Point taken.  I guess we are only disagreeing on the impact.

> i.e., when it says there was a spurous timeout and there was not.

I believe I came across a mail (reading mail after long vacation
is a pain...) pointing out that it is not.  I guess Reiner can
provide us with some data on his experience with Eifel.

							K. Poon.
							[email-masked]

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 21 Jan 2002 23:43:58 +0100

sorry for joining this discussion so late ...

Some comments to this an previous mails ...

>provide us with some data on his experience with Eifel.

I thought the Eifel algorithm was sufficiently robust in detecting spurious 
retransmits. However, Pasi Sarolahti found this case where the Eifel 
algorithm fails due to what appears to be a flaw in the current RFC1323. It 
also seems that there had been unfinished efforts [update to RFC1323 by 
Jacobson, Braden, Borman Feb. 97] that (among other things, I guess) fixed 
that part of RFC1323.

So, as it stands, I either require this fix in an update to the Eifel 
algorithm ID, or somebody rethinks RFC1323. I know that there are a number 
of lingering issues with it. So, maybe this is (again) the time.

Concerning a TCP sender response to a detected spurious timeout, I agree 
with Mark that reverting CC state needs to be combined with "adapting" the 
RTO. I would view it as a form of "speeding ticket" because the TCP sender 
(maybe) maintained a too aggressive RTO.

About reverting CC state after detecting a spurious timeout, don't forget 
that today's TCP (without Eifel) is probably the most aggressive choice. 
This is because today's TCP will forget about the flight of packets sitting 
somewhere in the network after a spurious timeout. Then it slow starts the 
(often unnecessary) go-back-N retransmits into the network thereby breaking 
'packet conservation'. Andrei has some very ugly ns2 TCP-Tahoe traces that 
show how a single spurious timeout causes TCP-Tahoe to do one unnecessary 
go-back-N after the other for quite a while. Maybe TCP-Tahoe doesn't even 
ensure network stability?

///Reiner

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

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 22 Jan 2002 12:15:58 +0000 (GMT)

> Jacobson, Braden, Borman Feb. 97] that (among other things, I guess) fixed

Feb. 97? Got a full citation? There's also:

http://www.kohala.com/start/tcplw-extensions.txt
TCP Extensions for High Performance: An Update, internet draft,
Braden, 1993.

There are more unfinished attempts at updating 1323?
(as opposed to the elided sack stuff, which finally got
decided on and published.)

thanks,

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 22 Jan 2002 14:30:25 +0100

>TCP Extensions for High Performance: An Update, internet draft,

Google only finds this 
http://www.ietf.org/proceedings/97dec/97dec-final-131.htm but I have a copy 
of the mentioned Feb. 97 ID. Maybe somebody else has link of an online version.

///Reiner

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 22 Jan 2002 13:36:55 +0000 (GMT)

> of the mentioned Feb. 97 ID. Maybe somebody else has link of an online version.

Jacobson, Braden, Borman, TCP Extensions for High Performance,
expired internet-draft, February 1997.

http://www.watersprings.org/pub/id/draft-ietf-tcplw-high-performance-00.txt
(watersprings RULES.)

L.

third time's a charm?