| |
PA2AGA > TCPDIG 05.06.96 20:51l 141 Lines 5436 Bytes #-10992 (0) @ EU
BID : TCP_96_117B
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/117B
Path: DB0AAB<DB0PV<DB0MAK<DB0SON<DB0SIF<DB0AIS<DB0NDK<DB0RWI<DB0OVN<PI8JOP<
PI8ZAA<PI8HWB<PI8VAD<PI8VNW
Sent: 960605/0631Z @:PI8VNW.#ZH2.NLD.EU #:10616 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA10512 ; Wed, 05 Jun 96 04:07:27 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.60/7.1) with SMTP
id AA00008222 ; Wed, 05 Jun 96 00:29:30 MET
Received: from pa2aga-10 by pa2aga with SMTP
id AA00008168 ; Wed, 05 Jun 96 00:17:28 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.60/7.1) with SMTP
id AA00004898 ; Wed, 05 Jun 96 00:17:24 MET
Date: Wed, 05 Jun 96 00:04:31 MET
Message-Id: <tcp_96_117B>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/117B
X-BBS-Msg-Type: B
I have read the document, and understand the the snoop module is based
in the presence of a Base Station (a gateway to internet) and a Mobile
Station : so that isn't directly aplicable to packet radio-nets.
However, it seems to me that the caching/retransmit strategy at Base
Station is a very good idea : the philosophy is to detect packets lost
because of the bad link (and not because of the traffic congestion), and
retransmit it imedialtly (using a second fast priority queue).
At the mobile side, the idea is to use a special ack (no standard) ("SACK,
Selective acknowledgment), that will allow to use a normal pc tcp/ip
software only enabling the "flag" to use this ack.
I think that the best solution should be to have an "intelligent" daemon
in each routers wich look the trafic on the radio channel, and should be
able to decide if datas had been lost because of the noise, because of the
traffic, or because of an hidden station (dificult to do ! :-), and then,
like the snoop idea, enable a fast retransmition at the router wich
detected a non trafic related loss.
The snoop idea consist of detecting the lost frames in the receiver side,
and use a NACK to activate the fast retransmition. If the data pointed by
the nack is not on the cache of the router, it will not be resent
(obviously). There are also ideas about the timers, wich seems very good.
What is not very clear for me, if the way they do NACK is correct (don't
know the datails of tcp/ip), and if that has bad consequences in our slow
and short(?) networks.
Maybe the day of a day of testing this kind of modifications has come !!
:-)
Saludos de Julian Operator of EA4ABB, EA n 37081 F 53 L VI
e-mail julian@ea4rct.clubs.etsit.upm.es
ampr-net julian@ea4rct.ampr.org packet radio ea4abb@ea4een.eam.esp.eu
Do not reply to julian@linux.ea4abb.ampr.org
------------------------------
Date: Mon, 3 Jun 1996 16:40:51 +0100 (BST)
From: Alan Cox <alan@cymru.net>
Subject: snoop module for tcp/ip
> While I have no problem with reliable link-level protocols
> retransmitting packets across a link, I have a real problem with
> network elements in the middle of the network playing around inside of
> TCP, which provides end-to-end reliability. This is a just a little
> bit disturbing since software does have bugs, and I don't want someone
> else's software inducing errors by checksum recomputation, etc.
Snoop resends frames, so it doesnt need to regenerate checksums thankfully
------------------------------
Date: Mon, 3 Jun 1996 20:22:25 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: snoop module for tcp/ip
I haven't read this particular paper yet, but I've seen numerous
proposals to "improve" TCP for wireless channels that invariably break
the end-to-end significance of the protocol -- which is bad. See
RFC-1144 on VJ header compression for an example of how to munge
TCP/IP headers in a way that maintains the end-to-end principle.
In general, I believe that it's a bad idea to modify TCP to handle
high loss rates unique to a wireless channel. It would be better to
implement some more focused robustness at the link and physical
layers. TCP has to run over a wide variety of physical media and it's
inappropriate to modify it for one particular media -- especially
since other media may well be involved even when a radio link is
included.
Phil
------------------------------
Date: Mon, 3 Jun 1996 21:19:14 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: snoop module for tcp/ip
>Snoop resends frames, so it doesnt need to regenerate checksums thankfully
Ah, that does sound better.
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.
So if you find yourself retransmitting often (i.e., often enough for
standard TCP performance to be noticeably affected), it may be
considerably more efficient to apply all this excess power to FEC
coding at a lower layer to avoid the need for so many retransmissions
in the first place.
Note that this discussion applies to retransmission at the link layer
as much as it does at the transport layer.
Phil
------------------------------
End of TCP-Group Digest V96 #117
******************************
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
| |
