Date: Sun, 7 Mar 93 04:30:05 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #63
To: tcp-group-digest
TCP-Group Digest Sun, 7 Mar 93 Volume 93 : Issue 63
Today's Topics:
hidden transmitter routing
Metro Based Addressed Plan (SIP/BIP)
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 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: Sat, 6 Mar 93 17:59:36 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: hidden transmitter routing
To: jackb@mdd.comm.mot.com (Jack Brindle)
> While we are on the subject of the physical layer and MAC, It would seem that
> this is the place we have the most to gain. The single biggest time waster is
> the key-up delay caused by the necessity for contention algorithms. We spend
> seconds making sure that an already clear channel is really clear before the
> tnc will key up and transmit. Of course, once the key up decision is made and
> committed, we are blind to anyone else coming on channel and colliding. The
> problems here are:
> 1) Inability to listen while transmitting due to single channel tx/rx.
> 2) Amount of time required to go from receive to full transmit (we are blind
> during this time also)
> 3) Need to make absolutely sure the channel is clear; we wait at least 1 second
> to assure this.
>
> All of these problems could be resolved by going to a central controller with
> full duplex operation, and full duplex local node operations. The next best
> thing
> is a full duplex central controller with half duplex local operation. The MAC/
> link protocol could also prove useful here to indicate channel busy, although
> in current tncs it is sufficient to simply place a modem tone on the air to
> keep tncs from transmitting.
This discussion has got me wondering how to best handle full-duplex
operation over a path that has a long inherent time-delay relative to
the typical packet size. Specifically, suppose we had a high-orbit
satellite or (I wish) a geostationary satellite with a portion of it's
up and downlink spectrum dedicated for packet use in full-duplex
mode. This would be an ideal repeater at say 1200 BAUD rates. But when
you start looking at the quarter second delay between when a ground station
transmits and when its signal is detectable by other ground stations, it
seems to me that this inherent delay can cause some serious problems
at the higher BAUD rates. This is one situation that doesn't seem to
get that much better by virtue of having a full-duplex repeater
available. Wouldn't this require a fix of a different nature?
Perhaps some form of token bus?
Tony AH6BW
------------------------------
Date: Sat, 6 Mar 1993 09:08:08 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Metro Based Addressed Plan (SIP/BIP)
To: TCP-Group@UCSD.Edu
bill.simpson@um.cc.umich.edu writes:
> Actually, there is already an address plan like this, call Metro Based.
>
> It was developed by Steve Deering at Xerox PARC for SIP (son of IP, or
> Steve's IP). It's for the future IP work going on right now in the IETF.
This really looks good. It really shows this guys on the ball! My example
pales by comparison :-) I haven't kept up with the IP addressing problem, but
am aware that 32 bits is insufficient for the not too distant future. This
64 bit scheme should be just what the doctor ordered.
---
Steve, N5OWK
------------------------------
End of TCP-Group Digest V93 #63
******************************
******************************