| |
PA2AGA > TCPDIG 07.06.96 13:32l 210 Lines 7810 Bytes #-10990 (0) @ EU
BID : TCP_96_118
Read: DD7MQ GUEST
Subj: TCP-Group Digest 96/118
Path: DB0AAB<DB0MWS<DB0RBS<DB0GE<LX0PAC<ON7RC<ON4AWP<ON6AR<PI8HWB<PI8VAD<
PI8VNW
Sent: 960607/0634Z @:PI8VNW.#ZH2.NLD.EU #:11766 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA10692 ; Fri, 07 Jun 96 03:29:11 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.60/7.1) with SMTP
id AA00008383 ; Thu, 06 Jun 96 23:41:59 MET
Received: from pa2aga-10 by pa2aga with SMTP
id AA00008350 ; Thu, 06 Jun 96 23:36:23 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.60/7.1) with SMTP
id AA00004911 ; Thu, 06 Jun 96 23:36:17 MET
Date: Thu, 06 Jun 96 13:55:59 MET
Message-Id: <tcp_96_118>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/118
X-BBS-Msg-Type: B
TCP-Group Digest Wed, 5 Jun 96 Volume 96 : Issue 118
Today's Topics:
snoop module for tcp/ip (6 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Tue, 4 Jun 1996 09:57:50 +0100 (BST)
From: Alan Cox <alan@cymru.net>
Subject: snoop module for tcp/ip
> The more I learn about information theory in general and coding theory
> in particular, the more I appreciate that retransmissions are a rather
> inefficient form of FEC coding. They're fine in taking an already low
> error rate down to essentially zero, but when they happen more than a
> few percent of the time, they begin to represent a significant amount
> of wasted power and channel capacity.
FEC however doesnt address the problem of being under a bridge for 40
seconds causing a lot of tcp backoffs and taking time to recover. It seems
to me this one is much closer to an improved fast retransmit recovery scheme
which doesnt have to drop back across the entire net.
So there are areas (hand offs are another one) where this kind of scheme can
help, and you can combine it with FEC.
Alan
------------------------------
Date: Tue, 04 Jun 1996 07:59:57 -0400
From: "Louis A. Mamakos" <louie@uu.net>
Subject: snoop module for tcp/ip
> FEC however doesnt address the problem of being under a bridge for 40
> seconds causing a lot of tcp backoffs and taking time to recover. It seems
> to me this one is much closer to an improved fast retransmit recovery scheme
> which doesnt have to drop back across the entire net.
But subnet/link-level reliability via a combination of FEC and
retransmissions would address this nicely, and further would work on
unmodified TCP implementations which are not connected to the RF
subnet directly.
Heck, we even have a "connected mode" AX.25 drive in NOS already which
is an implementation of this approach. You could certainly argue that
there's room for improvement regarding the underlying technology..
louie
------------------------------
Date: Tue, 4 Jun 1996 15:15:13 GMT
From: mdf@angoss.com (Matthew Francey)
Subject: snoop module for tcp/ip
>modify TCP
This "snoop" stuff is essentially an automatic "kick" for TCP connections.
As far as I can tell the TCP itself isn't modified.
>robust link layers
My only objections with "snoop" is that (a) it appears to be one-way, from
the base station to the mobile, and (b) it's too closely bound to TCP.
I suggest that we (desperately) need something that is balanced, knows
nothing about the higher level protocols, the frame is very trim-and-slim
so it can be used painlessly on very slow-speed links, and sports a
re-transmit protocol that is dirt simple to implement. Any other design
criteria? Some form of anti-HTS? Some kind of compatibility with existing
AX.25 hardware would be nice -- but here we can take the cue from the
IPv6 people and just make it possible to recognize a new-format frame
vs. an old one.
------------------------------
Date: Tue, 4 Jun 1996 12:58:03 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: snoop module for tcp/ip
>But subnet/link-level reliability via a combination of FEC and
>retransmissions would address this nicely, and further would work on
>unmodified TCP implementations which are not connected to the RF
>subnet directly.
Very true; good point.
There's probably some limit to the number of retransmissions that
should be attempted at the link layer before giving up, but it is true
that even a very long delay in the link layer is probably better than
dropping a packet altogether and relying on TCP retransmission
mechanisms. At least the long-delayed packet will get things flowing
again without having to wait for a TCP retransmission timeout that may
be backed way off.
>Heck, we even have a "connected mode" AX.25 drive in NOS already which
>is an implementation of this approach. You could certainly argue that
>there's room for improvement regarding the underlying technology..
Bingo.
Phil
------------------------------
Date: Tue, 4 Jun 1996 13:34:16 -0700 (PDT)
From: KF6AZM <eabu927@ea.oac.uci.edu>
Subject: snoop module for tcp/ip
Anyone know if those $15 RF modem circuit boards are still available for
the microwave links? If you have the address to the Ham who sells them
please post it again, thanx....think they're for 10Ghz...
On Sun, 2 Jun 1996, Alan Cox wrote:
> > Could some gods (like Alan Cox, Phil Karn, etc... :-) give their opinion
> > in the list. That should be very nice to see it ported in nos or linux
> > systems, and test it in our slow radio networks !!!
>
> Being listed before Phil.. good grief ;)
>
> I've looked at it a little. The basic idea is to generate retransmissions
> locally. The document isnt clear however on how it handles keeping
connection
> state nor the impact it potentially has on the TCP protocol bugs (RFC1337
> and draft-heavens...). Its on my too implement list shortly after the next
> version of the radio modems turn up but unlike the way the imply its done,
> in user space.
>
> Alan
>
>
>
------------------------------
Date: Tue, 4 Jun 1996 10:43:53 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: snoop module for tcp/ip
>FEC however doesnt address the problem of being under a bridge for 40
>seconds causing a lot of tcp backoffs and taking time to recover. It seems
>to me this one is much closer to an improved fast retransmit recovery scheme
>which doesnt have to drop back across the entire net.
Actually, it *can* -- if you're willing to interleave your FEC
encoding across spans quite a bit longer than 40 seconds. :-)
But seriously, Qualcomm Omnitracs deals with exactly this problem in
exactly the way I just described -- coding and interleaving -- though
I think the maxiumum duration of a "bridge fade" is limited to a few
seconds.
But your point is well taken. One approach to this particular problem that
I've been kicking around for years is the notion of an "ICMP Reachable"
message that routers could send to hosts to which they've recently
sent Unreachable messages when the problem has gone away. Obviously
this calls for some memory in the routers, so it would have to be an
optional performance-enhancing feature that hosts could use to kick
retransmissions before they'd otherwise occur normally.
Phil
------------------------------
End of TCP-Group Digest V96 #118
******************************
You can send your message for this bulletin
to: tcp-group@pa2aga on .AMPR.ORG-net
or: tcpaga@pi8vnw.#zh2.nld.eu on BBS-net
------
NOT TO: pa2aga@pa2aga or pa2aga@pi8vnw.#zh2.nld.eu PLEASE!!
It will get posted automatically within a few days
Read previous mail | Read next mail
| |
