Subject: [tcpm] reset: seeding RTO in 3WHS

From: Mark Allman <[email-masked]>
Date: Thu, 12 Aug 2010 09:17:23 -0400

Folks-

I have just read through the thread on seeding the RTO during the 3WHS
when using larger initial windows.  The notes I sent a few weeks back
still apply in my mind.  But, I think there is a big picture issue we
need to puzzle through before we consider when to seed the RTO ...

Whether we seed in the 3WHS or the first flight of data seems immaterial
if we reduce the default initial RTO from 3sec to 1sec (a proposal that
is out there in draft-paxson-tcpm-rfc2988bis-00.txt).  I.e., regardless
of whether you seed in the 3WHS or not the RTO is going to end up in the
same place when transmitting the first data segment.  

So, it seems to me that before we try to puzzle through this seeding
business we should figure out if we just want to make the change to the
default value.  If we do then lets forget this seeding business.  If we
don't then we can consider whether this seeding in the 3WHS is a good
idea or not.

My two bits ...

allman

--
Mark Allman -- ICSI -- http://www.icir.org/mallman/

---

From: Jerry Chu <[email-masked]>
Date: Thu, 12 Aug 2010 09:16:10 -0700

Mark,

> don't then we can consider whether this seeding in the 3WHS is a good

Agreed 100%. So the question really is if the WG is ready to adopt
draft-paxson-tcpm-rfc2988bis-00.txt. I think the only outstanding question on
the initRTO=1sec proposal is why not try to reduce minRTO as well and I
was asking why the two things need to go together (see my 6/28/10 email).

Since you have done some study on the overall impact of minRTO perhaps
you can share your thought on this?

Thanks,

Jerry

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

---

From: Mark Allman <[email-masked]>
Date: Thu, 12 Aug 2010 16:15:50 -0400

Jerry-

> I think the only outstanding question on the initRTO=1sec proposal is
> why not try to reduce minRTO as well and I was asking why the two
> things need to go together (see my 6/28/10 email).
> 

I have done so previously (Feb/2010 and at other times) and just went
and grabbed the text.  Basically, I think changing the initial RTO (as
in our draft) is fine, but the min seems like a much murkier situation
to me.  So, I'd rather not block on changing the min to see the initial
RTO changed.  

The old text:

  One problem with the minimum is we don't know what to set it at [*].
  The finding in [AP99] is that as you reduce the min you take more
  spurious timeouts.  The tradeoff seemed fundamental to us.  But, given
  our methodology (trace driven simulation) we could not really tell the
  impact of the spurious timeouts.  So, we just sought to minimize them
  in the spec.  I know some TCP implementations are being pretty
  aggressive with the min these days.  But, it is not at all clear to me
  whether this is a net win or net lose.  I.e., is the win in terms of
  peppiness to needed retransmits still a win when it is played against
  the consequences of a spurious transmit (i.e., setting cwnd = 1)?
  Perhaps there is a sweet spot that is < 1sec whereby this tradeoff
  better balances and we should be using that.  But, it'd take a big
  experiment to show that, I think.

  [*] Maybe there is work that I just don't know about and if so I'd
      like to be pointed at it.

Also in that Feb email was a wondering I have off-and-on had ...

  Another thing I have wondered about from time to time .... Much like
  Early Retransmit could we have some sort of early RTO when the cwnd
  size is small?  When the window size is small it seems that the
  downside of making a bad rexmt decision is not as bad as when the cwnd
  is large so it might pay in terms of responsiveness to RTO sooner.
  Also, as the cwnd gets larger we have better loss recovery techniques
  that should come into play that can repair lots of loss without
  involving the RTO and so perhaps by being overly aggressive in the RTO
  we just hurt ourselves.  Finally, as the cwnd gets bigger that means
  we are transferring more data.  And, the longer a connection goes the
  less important the fine-grained responsiveness matters.  Just a random
  thought ...

(Note, I would not advocate that for inclusion in an 2988bis.  If there
was interest in working this out then that'd seem to me to be something
experimental at first.)

allman

---

From: Alexander Zimmermann <[email-masked]>
Date: Fri, 13 Aug 2010 10:42:59 +0200

Hi Jerry,

I had the same discussion with Mark a while ago, whether or not ever
we should include the reducing minRTO stuff into the 2988bis doc or
not. Mark persuaded my that it is better to do not do so in order to
not block the doc.

However, since feb, nothing is happened... So I think we should decide
NOW if the WG would like to adopt the doc as it is (without minRTO
adjustment) or not.

Alex

---

From: Jerry Chu <[email-masked]>
Date: Tue, 17 Aug 2010 14:50:28 -0700

Wes & David,

It looks like 2988bis is ready for adoption as a WG item. Please let us know
what to do next.

Notat that besides reducing minRTO, a couple of other issues have been
brought up and discussed, one from Gorry Fairhurst on the implication of
SYN RTO expiry, the other from Markku on slow links with a larger IW.
We (Mark/Vern/I) will revise the draft to capture both discussions in the near
future.

Thanks,

Jerry