Re: [colorforth] /. and the new bios

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 20 June 2004 09:07 pm, Kurt B. Kaiser wrote:
> Yes, IMHO my tools, e.g. Gnus, are much better for lists.  Although
> some of the fora are still text oriented, the web fora, like Yahoo
> Groups, are terrible.  Slow, too much navigation, no filtering, etc.
> I get my Yahoo group by email.

You're missing the point.  Yahoo! is heavily graphical because they're on 
the web, employing push media tactics to sell products and services.  
This, if anything, is at most a technicality.  This has nothing 
what-so-ever to do with the fact that Yahoo! Groups being a bulletin 
board.

My point is that the existance and very popularity of it suggests that 
BBSes are not dead.  For another, non-advertising example, one need look 
no further than phpBB, which seems to be used literally everywhere.

> I was referring to the situation where we had to go back to dial-up.
> Is there a way to connect DSL to DSL? (Assuming I could get DSL, which

No, because it's designed to connect to the telephone company's central 
office.  However, I would also like to point out that there is no way to 
connect a modem to a modem either -- no modem I've ever seen has had the 
facilities to simulate a ring signal, or even a dial-tone.

That being said, it IS possible to connect one user via DSL to another 
user via DSL, in precisely the same way someone with a dial-up modem 
would connect to another user.  The only difference is that a DSL 
resembled an Ethernet network, and is therefore packet switched, not 
circuit switched.  To create a point-to-point connection involves the 
creation of a VLAN on the telco side -- not something they're likely to 
do, but given the nature of the Internet, IS something that is easily 
done at the end-points (and indeed, is highly recommended that this be 
the case anyway).  I know this for a fact, because where I work, we have 
literally thousands of customers who connect to their clients (and vice 
versa) this way.

> I can't.)  Maybe ISDN is useable in that situation?  But generally,
> I thought dial-up was limited to 56Kb/sec.  I'm getting 3 -4 Mb/sec
> down with cable.

Yes.  So?  These things are all still way beside the point I was trying 
to make, which is, BBS != Slow Dial Ups.

> OK, I'll bite.  What's a good replacement for TCP in a wireless
> application?

None as yet, but that doesn't change the fact that TCP is a rancid 
protocol to use for long-haul wireless networks (which will, at some 
point, be necessary for use if you were to build an entirely part 15 
network).  I openly challenge you to use TCP/IP on an amateur radio 
link, both raw and over AX.25.  You'll be quite surprised at how many 
packets are lost, and how many connections are just down-right dropped.

NB.  802.11b gets around this problem by specifying explicitly a range 
which guarantees all nodes are sufficiently close to each other that 
packet loss due to natural phenomena isn't an issue, normally.  However, 
as the nodes in competing WLANs gain in density, OR as the nodes in the 
same WLAN gains in number, the throughput characteristics of 802.11b are 
measurably worse than even 10-base-2.

However, many researchers, both professional and amateur alike, are 
working towards achieving a protocol, many of which are based on TCP by 
modifying its semantics.  I also know that the IETF itself has a 
replacement for TCP in the pipeline, though it is expected to be used in 
only niche situations (having just woken up, I can't remember the name 
right now), which may include wireless, but I'm not too sure.

One solution to the problem is to modify TCP in two ways:

a) packet retransmissions doesn't resend the actual data; instead it 
sends out redundancy codes so that the receiver can perform 
error-correction instead (often times, redundancy codes take less time 
to transmit than the original data anyway, so if this does occur, at 
least it'll be faster to transmit and therefore more responsive), and,

b) Let TCP acquire and learn about the link state (by monitoring requests 
for retransmissions) to automatically adjust how much ECC gets sent with 
the regular data payload up-front, so that retransmissions are minimized 
or eliminated all-together.  Although packet sizes get bigger, the link 
capacity actually increases, because it eliminates the time spent 
turning off the receiver, switching the antenna to the transmitter, 
spitting out a preamble and the request packet for a retransmission, 
stopping the transmitter, switching the antenna back to the receiver, 
etc.  All these steps are measured hundreds of nanoseconds on 802.11b, 
which when you think about it, IS a significant fraction of a bit-period 
at 11Mbps speeds.  And this has to happen TWICE, PLUS the fact that the 
packet retransmission request must compete for the same medium using the 
same CSMA/CA rules as any other packet.  Ouch.

This method, though not directly addressing TCP per se, is what Phil Karn 
(perhaps most widely known for his influence on TCP itself, so I suspect 
he should know best) proposes, and is experimenting with this technology 
in an amateur radio environment, easily one of the harshest radio 
environments on the planet.  If it works there, it'll work for 
everybody.

- --
Samuel A. Falvo II
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA1vbqvwDm/l0jx/IRAlTLAJ0R6/xHHhWHFPluP8X7ij+GjC95MgCdFJsQ
Ye7nTJIMwqjoCpS38uNEJk8=
=3Dir
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com