improving transport over lossy links ?

[Mike Tancsa]

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