Has anybody looked at this?

   From: sthaug@nethelp.no (Steinar Haug)
   Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
   Date: 16 Jul 1996 17:25:04 GMT
   Organization: Nethelp Consulting, Trondheim, Norway
   NNTP-Posting-Host: trane.uninett.no

   [Ignatios Souvatzis]

   |      TCP itself as a very poor behaviour if you have > 50% packet
   |      loss on a link. By design TCP assumes that links (physical
   |      links) have a low packet
   |   
   |   This is true for classical TCP. However, some RFC (was it 1323(?))
   |   proposes a mechanism to selectively NAK holes in the stream, which
   |   would help. I'm not aware wether this is implemented anywhere.

   You may find the following of interest.

   Steinar Haug, Nethelp consulting, sthaug@nethelp.no
   ----------------------------------------------------------------------
   From: Hari Balakrishnan <hari@cs.berkeley.edu>
   To: end2end-interest@ISI.EDU, tcplw@bsdi.com
   Subject: TCP SACK implementation available
   Date: Wed, 10 Jul 1996 13:41:17 -0700

   An implementation of the TCP SACK option based on the Jan. '96 IETF Draft 
   (Mathis/Mahdavi/Floyd/Romanow) is available from:

   ftp://daedalus.cs.berkeley.edu/pub/tcpsack/

   The implementation is in the BSD/OS 2.1 kernel and is alpha code.
   Source modifications to tcpdump (to handle SACKs) are also
   included, as is a BSDI binary. Some (minor) additions and
   modifications are planned to the kernel code in the near future.
   This version of SACK has been in operation for several weeks now at
   UC Berkeley (as part of the Daedalus project testbed,
   http://daedalus.cs.berkeley.edu/), and for a few days now for
   cross-country transfers.  Preliminary cross-country experiments
   performed over the last week across 16-18 Internet hops indicate a
   throughput improvement of between 30 and 50% on average over Reno,
   without violating any of the standard congestion control and
   avoidance mechanisms of TCP.

   Many thanks to Sally Floyd (LBNL), Srini Seshan (IBM), Vern Paxson
   (LBNL), and Randy Katz (UCB) for several suggestions, comments and
   help.

   Please send any comments, suggestions, bug reports, etc. to
   hari@cs.berkeley.edu

Sounds promising to have a starting point for an implementation, (or
maybe even and endpoint) given that my packed drop rate to/from pain
is around 50% during the week.

Regards,
	Ignatios