OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > TCPDIG   11.01.98 20:50l 121 Lines 4675 Bytes #-10105 (0) @ EU
BID : TCP_98_4
Read: GUEST
Subj: TCP-Group Digest 98/4
Path: DB0AAB<DB0ZKA<DB0LX<DB0CZ<DB0GE<LX0PAC<ON7RC<ON1BWP<ON6AR<PI8HWB<
      PI8VAD<PI8VNW
Sent: 980111/1650Z @:PI8VNW.#ZH2.NLD.EU #:9860 [Hoek v Holland] FBB5.15c $:TCP_
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : TCPDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA588 ; Sun, 11 Jan 98 16:36:53 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
	id AA00005990 ; Sun, 11 Jan 98 16:34:49 MET
Date: Sun, 11 Jan 98 16:24:36 MET
Message-Id: <tcp_98_4>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/4
X-BBS-Msg-Type: B

TCP-Group Digest            Sun, 11 Jan 98       Volume 98 : Issue    4

Today's Topics:
                          TCP/IP over radio

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.
Loop-Detect: TCP-Group:98/4
----------------------------------------------------------------------

Date: Sun, 11 Jan 1998 11:53:34 +0900 (JST)
From: noriton@netwk.ntt-at.co.jp (Norito NEMOTO)
Subject: TCP/IP over radio

at <2654@iw1cfl.ampr.org>
iw1cfl@iw1cfl.ampr.org wrote

>> I have just read about the question of the usefulness of VC mode over
>> radio. I think that in a strong IP-only environment this is not a good
>> choice. I notice some facts:
>> - On ATM systems the most used protocol il AAL 5, that is a connectionless
>> service (is not assured that the cell you transimit arrives at the other
>> level);
>> - On public networks, interconnecting LAN, is preferred Frame relay
>> network (actually in italy is almost FR-over-ATM) rather X.25 network
>> even if the latter has a volume taxation, rather than a time-taxation;
>> So why if the rest of the world is abandoning the idea of a connected
>> L2 layer under IP, we have to stay to an L2  connected service to transmit
>> tcp?

Its good idea.
I think that we must use other(not AX.25) L2 and L3 protocols.

>> The big problem I see on ampr IP network (and on digital data transmisson)
>> is due that ax.25 doesn't make a forward error correction: so
>> you loose a 256 byte packet even if only a bit is wrong.

Yes, I think so.

>> In fact ATM/FR/X.25 runs on optical fibers with a very low error rate,
>> but if we (using FEC) could decrease the hop-to-hop error ratio, the
>> end to end acknowledge of TCP is sufficient.

I am making like a you think system.
Now testing.

    800kbps MSK or 808kbps SS physical modem (faster is better)
    hardware Vitabi FEC
    used MACA, canceled hidden terminal.

and L3 exchange protocol
    3rd layer exchange by CALLSIGN,
                  (no use RSPF, because consider no-IP user)
    not use completely path, use pop by pop dynamic routing
                  (radio link status and topology often changed )
    choice small deley time path, not shortest
                  (shortest path is not always best)
    all station same system
                  (if there is base, who become base? who decide it?)
    no flow control, no errer correction, no retry, at end to end
                  (that is TCP or other protcol besiness)

>> Anyway, if an IS have to make hop to hop ack, it must have sufficient
>> memory and processing power to deal with a retraqsmission queue for every
>> VC that uses it, rather than have ony one queue for port. At 9600 bps
>> is not a concern, but on an high spped microwave link thi could slow down
>> the transmission sightly.

We made 808kbps wide area link system at 2.4GHz SS.
Alredy tested 20km trancefar completly.

>> Maybe is more useful thing about an 'amateur frame relay', with FEC
>> and if an IS receives a bad frame, simply drops it.

Okey!
Please expect next DCC.
we are going to attend DCC meeting with many paper;-)

#Of course, we welcome to discuss about this proposal.

Norito  JH1FBM
-------------------------------------------------     o       o
 Norito Nemoto / JH1FBM   Nakano-city, Tokyo,Japan     \_(((_/
                                                       /     \
    Packet Radio User's Group / PRUG96 project     ___/  n n  \__
       in charge of FEC chip, MACA, and FBPASS.   (       o      )
                                                   \__        __/_
        E-mail  noriton@netwk.ntt-at.co.jp            \ ^ ^ ^ \_/ |
        WWW     http://www.nemoto.com/                 \ ^ ^     (
  Network Applique'tion Laboratory Mascot "TOCKALI kun" \______/\_|

------------------------------

End of TCP-Group Digest V98 #4
******************************





Read previous mail | Read next mail


 12.09.2025 05:00:19lGo back Go up