Date: Wed, 27 Oct 93 04:30:02 PDT
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 #279
To: tcp-group-digest
TCP-Group Digest Wed, 27 Oct 93 Volume 93 : Issue 279
Today's Topics:
BOOTP docs
Data Compression
Dynamic IP Addresses
Dynamic IP Addressing (3 msgs)
IP address coordinator in ENY section
RE: Dynamic IP Addressing (2 msgs)
VJ header compression on radio links (2 msgs)
While we're at it
XLZW
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: 26 Oct 93 11:02:32 CDT
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: BOOTP docs
To: <TCP-Group@ucsd.edu>
Does anyone have any instructions for using BOOTP in a NOS environment.
I've found the RFC's but I'm not sure how well the NOS implementation
follows it yet. Is anyone running BOOTP with NOS? Thanks.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: Tue, 26 Oct 93 17:50:47 GMT
From: kf5mg@kf5mg.ampr.org
Subject: Data Compression
To: tcp-group@ucsd.edu
The data compression book that I mentioned in a previous append is called
'The Data Compression Book'. Catchy title... huh? It's written by Mark Nelson
and is published by M&T Books. The ISBN number is 1-55851-216-0.
73's de Jack - kf5mg ( running JNOS in a 735K - OS/2 2.1 Dos Box! )
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
-------------------------------------------------------------------------
| "I am Homer of Borg.... Prepare to be assim.... oooo Donuts." |
-------------------------------------------------------------------------
------------------------------
Date: Tue, 26 Oct 1993 15:21:28 -0500 (CDT)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Dynamic IP Addresses
To: TCP-Group@ucsd.edu
kf5mg@kf5mg.ampr.org says:
> Someone suggested we look at doing some sort of dynamic IP Addressing
> for a new, radio network project that we're starting to work on.
MIKEBW@ids.net says:
> You might look at bootp, since the code for it is nominally already in
> NOS. I don't know if the code works or not, but it might.
A note in the source says it doesn't work as I recall. Normally bootp is
used to issue an IP address based on an Ethernet address, but could be used
along with an amateur callsign. I think the problem is that every expected
address must be in a table. They're not really dynamic, but the administrator
can change IP addresses without the LAN user being aware of what their number
is. One method may be to have an IP Address server running which is accessed
via the NOS mailbox, and the user answers a couple questions and receives an
IP address to use which times out after an hour or so of non-use. Another
may be similar to an ARP request packet to QST. A DIP request? :-) The user
would say hello and any listening server (one per frequency hopefully) would
listen up and answer, thus being automated. I may be wrong, but I don't think
anything in NOS does this type of thing yet.
---
Steve
------------------------------
Date: Tue, 26 Oct 93 12:32:52 MET
From: pa0gri@tophat.cdh.cdc.com
Subject: Dynamic IP Addressing
To: MIKEBW@ids.net (Mike Bilow)
> You might look at bootp, since the code for it is nominally already in
> NOS. I don't know if the code works or not, but it might.
>
> -- Mike
>
For supplying the (a) IP address yes, but using dynamic IP addresses for
SMTP etc, sounds like a bad idea to me. You would need a second level
of addressing for moving targets. (out of sight, next on gets its just
used address !! , revalidate , forward all routes ....)
Regards, Gerard.
------------------------------
Date: Tue, 26 Oct 93 10:17:23 -0400
From: jfjr@mbunix.mitre.org (Jerome Freedman)
Subject: Dynamic IP Addressing
To: pa0gri@tophat.cdh.cdc.com
Check out "Protocols for Mobile Internetworking" PHd Theis by J. Ioannidis
at Columbia
------------------------------
Date: Tue, 26 Oct 1993 15:46:20 -0500
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: Dynamic IP Addressing
To: kf5mg@kf5mg.ampr.org, tcp-group@ucsd.edu
Besides BOOTP, there is another protocol written up (don't remember if
it was a rfc, just a draft, or not even a draft) that specifically
addressed the reuse issue (ie when is it safe to re-use the address)
I will have to dig through my printouts at home to see if I can find it.
regards,
miltonm
--
Milton Miller KB5TKF miltonm@austin.ibm.com
I don't speak for IBM
------------------------------
Date: Wed, 27 Oct 93 00:03:59 -0400
From: foxworth@bnlls1.nsls.bnl.gov (Bob Foxworth)
Subject: IP address coordinator in ENY section
To: tcp-group@UCSD.EDU
I spoke with Dana, wa2wni on the phone this evening. He lives in the
Albany, NY area and is associated with NorthEast Digital Association.
The IPers in the ENY section are interesting in setting up subnetting
for routing etc. Right now there are 2 problems, the existing ENY
addresses are "flat" and there has been no recent communication with the
address coordinator of record, n2igu. I am posting this here to see if
anyone knows what is happening in ENY with address coordination and
to see about sanctioning having wa2wni become involved with re-structuring
the addressing for that area. I am coordinator for NLI in New York,
and Dana called me with respect to that. I would favor having someone
who is reachable and actively involved in IP activity there take over
this job as it would reduce requests to me for help, which I can't
handle as I am out of the area. The ENY people want to set up a scheme
similar to what is going on in WNY, however I don't have recent details
of what they are doing in WNY beyond that they are extensively sub-
netting.
Please send me mail if any of you have input on this problem.
I am handling all NLI section addressing. The best way to reach me
is via telephone in the evenings at 516-585-7559. I have been off
the air (IP and AX.25) for a while now and my CBA is no longer valid.
My internet address is valid for those with such access. The closest BBS
is KC2FD-4 (ZIP 11727) who can hand off traffic to me. Please circulate
this info to anyone who may need to have it. 73 Bob
------------------------------
Date: 26 Oct 93 09:35:31 CDT
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: RE: Dynamic IP Addressing
To: <TCP-Group@UCSD.EDU>
>> You might look at bootp, since the code for it is nominally already in
>> NOS. I don't know if the code works or not, but it might.
>>
>> -- Mike
>>
>For supplying the (a) IP address yes, but using dynamic IP addresses for
>SMTP etc, sounds like a bad idea to me. You would need a second level
>of addressing for moving targets. (out of sight, next on gets its just
>used address !! , revalidate , forward all routes ....)
>Regards, Gerard.
Thanks.... I've requested the RFC's mentioned in the BOOTP code. Maybe
I'll be able to figure them out.
As for Gerard's concern about moving targets... the main thing I'm
looking for is a way to assign an IP address for a client that doesn't
normally run TCP/IP. I see NO reason why a simple client needs to have
a static IP number. No one is going to ever try and connect to the
client so no one needs to have an permanent IP number for him.
When I mentioned mobile stations, I really meant semi portable
stations. Something where you would go from place to place and connect
to the server each time. I'm not looking at doing a completely mobile
system. I.E. not something that constantly follows you around as you go
from one service area to another. I'm trying to cover the simple cases
first. I'll let the paid professionals work out the follow-me-roaming
stuff.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: Tue, 26 Oct 93 15:54:34 PDT
From: brian@nothing.UCSD.EDU (Brian Kantor)
Subject: RE: Dynamic IP Addressing
To: tcp-group@nothing.UCSD.EDU
It seems to me that RARP and/or BOOTP could be used to assign addresses.
If a station in each community were to accept responsibility for doing
so, and forwarding the address info (a tuple containing
IP address assigned
date/time assignment was made
identifier of agency doing the assignment
link address (AX.25 callsign/ssid or the like)
to a central collection point, mobile/portable IP assignment wouldn't be
a problem.
Simply, a station would have an IP address assigned to its callsign/ssid
until a newer assignment is registered at the central point (the central
nameserver) or until the assigning agency (the community host) indicates
that the callsign/IPaddr pair hasn't been used for a year or so.
Regional concentration of this data would solve the problem of people
who are like driving cross-country. With a fast enough underlying
network update mechanism, you could even handle stations in fast airplanes.
We've got LOTS of IP addresses; using up a few extra for a year when
stations move isn't a problem.
- Brian
------------------------------
Date: Tue, 26 Oct 1993 17:35:28 -0500
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: VJ header compression on radio links
To: MIKEBW@ids.net, louie@uunet.uu.net, tcp-group@ucsd.edu
I think there are a few issues to be addressed:
1) VJ Header compression was designed for point-to-point links. At
the very least, you would need a compressed slot table for each
router and direct host that was talking to you, and you would need the
hardware address to tell these apart.
2) VJ header compression requires that either a "bad frame detected"
be sent to the decompresser, or the slot never be compressed. Since
we *can not* do the first, we must never compress the slot id.
3) VJ is designed for reliable links. When you get an unreliable
link, you basicly discard all packets from the error until the
retransmit of the frame in error (the look like tcp checksum
errors, as stated in rfc1144). So error recovery is no better than
vanilla ax.25 connected mode (except you are allowed a bigger window,
which means even more data retransmitted).
4) VJ over vc would probably make some sense, but the protocol issues
noted by others would need to be taken into account (vc reliablity).
The increase in rtt variation should factor in automatically if the
errors happen with any reliability.
5) I was reading the VJ's SIGCOMM '88 paper. There was a footnote
that the rto should be rtt + 4 * variance, not 2 * var as in the
original paper. I wonder which nos is using? (might still be 2*,
in which case it needs to be fixed.
6) Over vc links, the rto might need to be increased even further,
depends on retransmit drop count -- how many times do you retransmit
before you drop the link and flush your packets? (I think the answer
is nos presently drops exactly one tcp packet if the vc curcit fails
and is re-established).
Ok, that should be enough discussion for a few days :-)
milton
--
Milton Miller KB5TKF miltonm@austin.ibm.com
I don't speak for IBM
------------------------------
Date: Wed, 27 Oct 93 12:25:18 +1000
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: VJ header compression on radio links
To: miltonm@inetnode.austin.ibm.com (Milton Miller), MIKEBW@ids.net,
In atricle by Milton Miller:
>
> I think there are a few issues to be addressed:
>
> 1) VJ Header compression was designed for point-to-point links. At
> the very least, you would need a compressed slot table for each
> router and direct host that was talking to you, and you would need the
> hardware address to tell these apart.
>
> 3) VJ is designed for reliable links. When you get an unreliable
> link, you basicly discard all packets from the error until the
> retransmit of the frame in error (the look like tcp checksum
> errors, as stated in rfc1144). So error recovery is no better than
> vanilla ax.25 connected mode (except you are allowed a bigger window,
> which means even more data retransmitted).
>
> Ok, that should be enough discussion for a few days :-)
Why not fuel the fire :-) Here's a roughed out paper/tech report that I
started this week.
Extending TCP/IP Header Compression
over Multiple Links
W. Toomey
Department of Computer Science
University College
The University of New South Wales
Australian Defence Force Academy
Canberra, ACT
October 27, 1993
Abstract
TCP/IP header compression, described in RFC 1144, increases data throughput
over low speed links. This technique is limited to TCP/IP connections
between two hosts joined by one point to point link.
This paper extends this technique so that it can be used in situations
with multiple links that are not specifically point to point.
Warren Toomey, e-mail: wkt@csadfa.cs.adfa.oz.au
1 Introduction
1.1 Limitations Imposed by RFC 1144 Compression
a) The source and destination of the compressed TCP connection must be
connected by a single point to point link.
b) Packets will not be misordered by transmission from source to
destination.
1.2 Extending RFC 1144 Compression
RFC 1144 header compression can be extended to work over multiple links by
adding extra information that allows packets to be routed. Specifically,
the following fields from the IP header must be included:
o The IP address of the destination.
o The IP address of the source. This allows any ICMP error messages to
be returned to the source.
o The time to live field. This allows old packets to be removed from
the network if there is no adequate route for them.
1.3 Limitations Imposed by the New Compression
a) Packets will not be misordered by transmission from source to
destination.
b) Routers that forward packets from the source to the destination must be
able to forward compressed TCP/IP packets.
2 Functional Specification
2.1 Packet Format
The format of a compressed TCP/IP packet is that of RFC 1144, extended to
allow IP routing. The format is shown in the following diagram.
+----------------+----------------+----------------+----------------+
| Source IP Address |
+----------------+----------------+----------------+----------------+
| Destination IP Address |
+----------------+----------------+----------------+----------------+
| Time to live | Change flags | Connection # | TCP checksum |
+----------------+----------------+----------------+----------------+
| TCP Checksum | Urgent Pointer | Delta window | Delta Ack |
+----------------+----------------+----------------+----------------+
| Delta sequence | Delta IP ID |
+----------------+----------------+
Figure 2: Compressed TCP/IP Packet Format
All fields except the first three are unchanged from RFC 1144. The
first three fields hold the source/destination IP address and time to live
value, and are used exactly as their counterparts in a standard IP header.
2.2 Compression Negotiation
The source and destination cannot assume that the other understands TCP/IP
header compression. Therefore a negotiation phase during connection setup
needs to be performed in order to allow header compression to commence.
This is achieved by setting a `COMPRESS HEADERS' TCP option in the SYN
packets exchanged during connection setup. If a source/destination sends a
SYN packet with a `COMPRESS HEADERS' option and receives a SYN packet with
a `COMPRESS HEADERS', then TCP/IP header compression can be performed
according to RFC 1144.
The `COMPRESS HEADERS' TCP option has the following form.
+----------+----------+--------------------+
| Kind= 25 | Size= 4 | Connection Number |
+----------+----------+--------------------+
Figure 3: `COMPRESS HEADERS' TCP Option
The `Kind' octet indicates the `COMPRESS HEADERS' option. The `Size'
octet indicates the size of the option, 4 octets. The `Connection Number'
holds the connection number to be used in compressed headers to the host
that sent the SYN with this option.
2.3 Problems with Compression Negotiation
Compression negotiation depends on the fact that a TCP instantiation knows
that header compression is available on this host, and that the routers on
the path between this host and a destination can forward compressed
packets.
This violates the principle that TCP should not know about the link
between itself and a destination, and it should not know about layers below
IP. There are two solutions to this problem:
o Alter a TCP implementation to know about header compression in a layer
below it. This ignores the problems raised above.
o Let the header compression layer rewrite SYN packets, adding the
`COMPRESS HEADERS' option to the SYN packet according to criteria that
will guarantee the limitations discussed in Section 1.4 are met. This
is kludgy, but we are already rewriting TCP and IP headers, so this is
not much harder.
The latter is recommended.
2.4 Other Details
o All routers between the source/destination must be able to interpret
and forward compressed packets, otherwise they will be discarded, and
header compression will be useless. It is suggested that routers with
TCP implementations also have full header (de)compression
implementations; if a router only routes, then only a small
modification to the IP layer is needed to interpret compressed
packets.
o Obviously we need a new link layer protocol id for the new type of
packet, for every link layer that will be used.
------------------------------
Date: 26 Oct 93 10:59:45 CDT
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: While we're at it
To: <TCP-Group@UCSD.EDU>
Warren vk1xwt writes:
> Does anybody have/know of something like an RFC for the XLZW data
>compression as used by many NOS flavours for SMTP mail transmission.
>Seems to me that this is useful throughout the whole Internet, and not
>just the Amprnet. Patches to sendmail for this also appreciated :-)
Do you want an RFC on the LZW compression stuff in general or just
the client/server communication part?
I've added LZW compression to both FTP and POP. ( The pop stuff has
problems where the socket if flushed too often, so lots of small packets
get sent out. The FTP stuff seems to work fine works on both ASCII file
transfers and directory list. ) The process if fairly strait forward.
I'd be glad to try and write down what I've been able to figure out. I
haven't been able to figure out how the data is actually compression in
NOS, but I have found a really good book that talks about the different
compression methods (Huffman, Adaptive Huffman, LZW-S, LZW-77, LZW-78,
plus several others.) I'll post the name of the book if anyone is
interested. It comes with C source.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: Wed, 27 Oct 93 11:08:33 CET
From: dk5dc@vnet.ibm.com
Subject: XLZW
To: tcp-group@UCSD.EDU
Sorry, there is probably NO RFC available yet.
LZW Compression has been roughly implemented by Anders Klemets
SM0RGV on Socket Level only.
Later on (somwhere in 1991) I added the XLZW Exchange as a transparent
extension to SMTP and NNTP. This has been adopted by Michael,
DB3FL just because WNOS and our local Version of NOS wanted to talk
to each other. Some time later, I've found that code in JNOS, too.
This is normal, because people don't think such special
Ham Radio extensions could be usefull for the whole
Internet.
The same thing happended (among others)
with that nnGpost() function, which automatically transfers
(via alias) a incoming smtp message into the NEWS System.
It popped up in other NOS Derivates, but the remarks where gone....
Peter Glasmacher DK5DC/AA6HM
+----------------------------------------------+
| AX25Net : DK5DC@DB0LJ.GER.EU (SMTP forward) |
| amprNet : dk5dc@dk5dc.ampr.org [44.130.17.60]|
| Internet: dk5dc@vnet.ibm.com |
| Bitnet : dk5dc@vnet |
| Vnet : D1PGLA AT DUESVM1 |
+----------------------------------------------+
------------------------------
End of TCP-Group Digest V93 #279
******************************
******************************