From owner-freebsd-net@FreeBSD.ORG Fri May 19 16:38:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB27016A421 for ; Fri, 19 May 2006 16:38:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4032343D53 for ; Fri, 19 May 2006 16:38:18 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.4P/8.13.4) with ESMTP id k4JGcHnY076441; Fri, 19 May 2006 12:38:17 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k4JGcGqI094659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 May 2006 12:38:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060519121104.1126b480@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 19 May 2006 12:38:31 -0400 To: Ian Smith From: Mike Tancsa In-Reply-To: References: <6.2.3.4.0.20060519110026.05820230@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new Cc: freebsd-net@freebsd.org Subject: Re: improving transport over lossy links ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 16:38:19 -0000 At 12:06 PM 19/05/2006, Ian Smith wrote: >Assuming that V.42 error correction is working properly - forced if need >be - there shouldn't =be= any data loss, however slow getting through, >this side of protocol timeouts of course. I can't guess your mystery >application, but often slower connections are better than dropped ones, >or even ones that spend half their time trying to retrain at high rates. Hi, Thanks for the reply. Even at 28.8 I am seeing loss with the connection dropping and seeing dropped packets (e.g. May 19 12:04:43 soekris4801 ppp[3404]: tun0: Phase: 1: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0) Error correction is on and negotiated, from the terminal server's perspective at least and I imagine the modem too Testing here at the office Card Type: LU1674 Chipset State: ACTIVE Active Port: S26 Transmit Rate: 28800 Receive Rate: 26400 Connection Type: LAPM/V42BIS Chars Sent: 215666023 Chars Received: 58090941 Retrains: 0 Renegotiations: 4 The application is TCP based and monitors remote machinery. (And no, there is no chance at this point to re-write the application). The transport is over a VPN (either IPSEC or OpenVPN) which ever deals better with the lossy connection. However, many of the sites have dynamic IP addresses which makes it a pain to use with IPSEC and FreeBSD. One think I observed with multi-link so far is that if I kill one of the connections, the modem does not tell ppp that it has lost carrier right away. Instead, I have to wait for the LCP echo timeout. In the mean time, I get 50% packet loss for about 20 seconds. However I can reduce that by setting the lqrperiod to a lower value. However, I dont want that too low, otherwise it spends all its time chewing up the link with LCP traffic. I was going to look at the one2many ng module to see if I can send out the same packets on both links at the same time as a sort of "as long as one packet gets there strategy" Although the customer doesnt use wireless right now, we might have some sites that would need it in the fture and this might be an approach. I imagine satellite users run into this as well no ? ---Mike