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

From: Mark Allman <[email-masked]>
Date: Fri, 11 Jan 2002 23:46:51 -0500

> Raise RTOmin to 5s then (-: At least to me, the usefulness of RTT
> sampling and RTO calculation as described in RFC 2988 decreases as
> the RTOmin keeps increasing as it just masks everything!  The
> point I am trying to raise is that the RTO algorithm in RFC 2988
> should not be the end of all (Reiner should agree (-:).  And I
> feel, just me (-:, that other algorithms are probably needed in
> different situations.

The comment about raising RTOmin was meant as an example.  I am not
advocating that approach.  I have not thought about what to do with
the RTO much at all and so that came off the top of my head as a
quick example.  The point was that you do *something* in an attempt
to prevent future spurious retransmits.

More generally, I have two lines of thinking on RTO estimation...

- Yes, different RTO algorithms may help things a bit in some
  cases, or even in general.  That is, I do not necessarily believe
  the current algorithm is the end-all of RTO estimators.

- The RTO should be fairly conservative.  The normal case should be
  that we repair loss using some other mechanism and the RTO should
  truely be the method of last resort for repairing loss and we
  should use it only rarely.

(I mostly think in terms of the second point -- that RTO
optimizations are less useful than scheme to try to prevent RTOs).

> Do you have evidence that the problem related to fast retransmit
> is significant?

There are studies in the literature that show reordering is a fairly
significant problem on some links (and reordering can cause
duplicate ACKs that trigger fast retransmit unnecessarily).

> > The current situation is that if you send a needless retransmit
> > (and hence add a packet to the network that accomplishes no new
> > work) you pay a price -- i.e., you slow down.  Now if we make
> > TCP realize this and undo things the price has been
> > substantially reduced.  So, there is really no incentive to try
> > to be conservative and easy on the network.  Therefore, it seems
> > to me (and others I have chatted with)
> 
> I don't understand the comments above.  If TCP can know for sure
> that it just has done a spurious retransmission, it should undo
> it.  I agree totally.  But it does not mean that there is no
> incentive to try to be conservative.  At least to some people, the
> issue with it is that what if TCP makes mistakes too often and
> does not react to real network problems as it does today.  

Sure, you should be able to recover from mistakes that you know you
made.  I agree completely.  Think about the extreme for a minute...
An example might be a connection in which every third packet sent is
a bogus retransmit.  So, a third of the packets we are spewing into
the network are worthless and are chewing up resources along the
path (bandwidth, processing, queue space, etc.).  Is this
acceptable?  I don't think so.  Currently, the TCP flow has to slow
down when it finds a loss.  So, there is an incentive to get the
decision correct -- i.e., if it decides something is a loss and it
really isn't then it needlessly slows down.  If we come up with a
good scheme that lets the sender continue to send at the same rate
even when the retransmit is determined to be bogus the incentive to
make good decisions is gone -- i.e., if we retransmit prematurely it
doesn't matter, we'll figure it out and recover without much of a
performance hit.

> If all routers now "punish" overly aggressive TCP traffic, the
> incentive to be nice is ample (-:

**if**

And, even if they did, I cannot imagine a scheme that a router could
reasonably implement that would be able to figure out how many
useless segments a particular flow is sending.  That would be a very
complicated and resource intensive algorithm to run on the fly in
the middle of the network, I think.

So, I think it is unreasonable to hope that the network is going to
protect itself from this particular phenomenon.

> I agree with the above.  But do they really need to go together?
> That's my question.  They can be deployed separately.

Yes, in my opinion.  They *do* need to go together.  If you are
making TCP more aggressive on one hand (reverting CC state) you also
need to make an effort to try to avoid such situations in the
future.

> My issue with new algorithms is that we need time to really see
> what they are doing.  And if there are multiple things going on,
> some effects may be masked and we cannot correctly determine some
> underlying problems.

Things do get tricky when they are mingled together.  And, to be
clear, I think there could be some good and useful research that
considers these things seperately.  But, from the point of view of
writing an RFC (we are using an IETF list here) I think we need to
couple these two things pretty closely -- at least until someone
shows that one without the other is OK.

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: Kacheong Poon <[email-masked]>
Date: Sat, 12 Jan 2002 13:42:00 -0800 (PST)

> decision correct -- i.e., if it decides something is a loss and it

I guess now I see why I didn't understand what you said...  It is not
an "incentive" to slow down after a loss, as far as I can tell.  There
is "incentive" for TCP stacks not to slow down.  TCP slows down now
because if there is a stack not doing it, you know what people will
say about it.  If a stack really wants to get the most from the network,
slowing down is properly the last thing to do.  

> doesn't matter, we'll figure it out and recover without much of a

If you look at it another way, there is no decision to be made now,
it is the "standard" practise.  If TCP has a timeout, it does slow
start and changes its rate of sending (ss threshold changes...).  This
is supposed to be good to the network, but not an incentive for a stack
to do because in some situations, this does not help anything at all 
(simple example is loss due to errors).  IMHO, I don't think you have to
worry about that TCP will never be slowed down.

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.

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.  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...

> protect itself from this particular phenomenon.

First, if routers can "punish" overly aggressive traffic, there is
an incentive for stacks not to do that.  Second, given that, the
worst thing a stack can do is to unnecessarily send useless (say
duplicate) packets, but without gaining unfair (the fairness 
determined by the routers) advantage.  Then what it hurts is itself,
as I mentioned above.  I don't believe routers need to spend time 
determining whether a packet is sent unnecessarily at all...

> need to make an effort to try to avoid such situations in the

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.

> shows that one without the other is OK.

I guess I cannot convince you )-:  But please don't get me wrong,
I am not saying that we don't need to find a better, say, fast
retransmit triggering mechanism.  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 as I asked previously,
I think we need another RTO algorithm.  I hope other researchers
can jump in and give their opinions.

							K. Poon.
							[email-masked]