netdev - Re: [PATCH] make _minimum_ TCP retransmission timeout configurable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Aug 2007 15:35:03 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rick.jones2@...com
Cc:	ian.mcdonald@...di.co.nz, netdev@...r.kernel.org
Subject: Re: [PATCH] make _minimum_ TCP retransmission timeout configurable

From: Rick Jones <rick.jones2@...com>
Date: Wed, 29 Aug 2007 15:29:03 -0700

> David Miller wrote:
> > None of the research folks want to commit to saying a lower value is
> > OK, even though it's quite clear that on a local 10 gigabit link a
> > minimum value of even 200 is absolutely and positively absurd.
> > 
> > So what do these cellphone network people want to do, increate the
> > minimum RTO or increase it?  Exactly how does it help them?
> 
> They want to increase it.  The folks who triggered this want to make it 
> 3 seconds to avoid spurrious RTOs.  Their experience the "other 
> platform" they widh to replace suggests that 3 seconds is a good value 
> for their network.
> 
> > If the issue is wireless loss, algorithms like FRTO might help them,
> > because FRTO tries to make a distinction between capacity losses
> > (which should adjust cwnd) and radio losses (which are not capacity
> > based and therefore should not affect cwnd).
> 
> I was looking at that.  FRTO seems only to affect the cwnd calculations, 
> and not the RTO calculation, so it seems to "deal with" spurrious RTOs 
> rather than preclude them.  There is a strong desire here to not have 
> spurrious RTO's in the first place.  Each spurrious retransmission will 
> increase a user's charges.

All of this seems to suggest that the RTO calculation is wrong.

It seems that packets in this network can be delayed several orders of
magnitude longer than the usual round trip as measured by TCP.

What exactly causes such a huge delay?  What is the TCP measured RTO
in these circumstances where spurious RTOs happen and a 3 second
minimum RTO makes things better?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html