Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 03:05:46 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FA5MHE028819 for ; Thu, 15 Jul 2004 03:05:24 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 73D728D779B; Thu, 15 Jul 2004 11:27:26 +0200 (CEST) Date: Thu, 15 Jul 2004 11:27:17 +0200 From: Andi Kleen To: David Stevens Cc: "Rusty Russell (IBM)" , netdev@oss.sgi.com Subject: Re: Fragment ID wrap workaround (read-only, untested). Message-ID: <20040715092715.GA23131@wotan.suse.de> References: <1089871078.3571.56.camel@bach> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 02:28:05AM -0600, David Stevens wrote: > My idea for solving this problem is to create an estimator for the > reassembly timer. The fundamental problem as I see it is that the > reassembly timer is fixed, and about 6000 times too long on a > fast network (and worse the faster networks get). Won't that make the worst case behaviour on a congested link much worse? e.g. consider a very congested link with variable RTTs. Or a link that works relatively smoothly and suddenly the RTT increases. Yes, running fragmentation over those is not a good idea, but still it should not be made worse. Your variable timer even with a smoothing algorithm in the RTT estimator will expire far too early and very likely drop a lot more fragments in this scenario than before. In general handling a link where the RTT increases would seem tricky with your scheme. Unlike TCP there is no retransmit to save the day. -Andi