STGEORGE@UNMB.BITNET (01/21/88)
Can anyone tell me the status of thw work being done to get around the limitation of TCP/IP to a hop of 15 nodes? Thanks.
lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) (01/22/88)
From tcp-ip-RELAY@SRI-NIC.ARPA Thu Jan 21 00:40:29 1988 Received: Thu, 21 Jan 88 00:40:26 PST by orville.nas.nasa.gov (5.54/1.2) Received: Thu, 21 Jan 88 00:41:41 PST by ames-nas.arpa (5.51/1.2) Message-Id: <8801210841.AA12538@ames-nas.arpa> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 20 Jan 88 14:17:55-PST Received: from UNMB.BITNET by CUNYVM.CUNY.EDU ; Wed, 20 Jan 88 17:17:52 EST Date: Wed, 20 Jan 88 15:16 MDT From: <STGEORGE%UNMB.BITNET@CUNYVM.CUNY.EDU> Subject: Hop problem To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa Status: RO Can anyone tell me the status of thw work being done to get around the limitation of TCP/IP to a hop of 15 nodes? Thanks. Said work is complete, in that the current limit is 255, assuming all intervening gateways only decrement the time to live by one. This has always been the state. Perhaps the particular IP you are running initializes the time to live at 15, assuming this to be an upper limit. There is also the existence of an implementation of a routing protocol called RIP, which assumes a distance of 16 is infinite. Perhaps this is causing you some problem. All you need do is correct all machines to initialize the ttl field to be more than 15, and you will win. I doubt seriously if anyone is trying actively to repair this as a default case. john
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (01/23/88)
Is an initial TTL of 64 large enough these days? (particularly given some of the things the packet-radio people are talking about - I saw a 30+ hop routing posted on pc-ip recently). jbvb
CERF@A.ISI.EDU (01/24/88)
The 30+ packet radio hop was a deliberate attempt at maximizing the number of nets/hops the packet traversed. I think 64 is still a reasonable maximum. We should be trying hard to design the system so the maximum hop count is far less than 64, of course. Vint
brescia@PARK-STREET.BBN.COM (Mike Brescia) (01/25/88)
The Internet Protocol Time to Live (TTL) field was introduced as a way of
detecting and supressing loops. Ideally, a packet would be timed as it passes
from source host through gateways, packet switches, satellite links and to the
destination, and further within the destination while awaiting fragments for
reassembly in the IP layer. Since clocks are not yet universally syncronized,
the only thing we see being done is decreasing the TTL within each gateway.
The IP spec. states that a gateway must decrease this field by at least 1
(otherwise it could possibly live forever).
Now, when the TTL is viewed as a field decremented by each gateway a packet
passes, it appears to be a hop count field. Packet radios or packet switches
are actual hops in a network, but do not alter the TTL field, even though we
sometimes saw queueing delays in the Arpanet in the 10-20 second range.
packet-radio people are talking about ... a 30+ hop routing
I think Phil Karn said something about that path being only about 10 seconds
long. Also, I expect that the radio hops were not doing gateway functions, so
they did not count the IP TTL field.
mikeCERF@A.ISI.EDU (01/26/88)
Mike, the "packet radio" referenced was not the DARPA packet radio but the amateur packet radio. I don't know how those systems handle the TTL field. The DARPA packet radio system didn't pay any attention to TTL except at gateways since the packet radio net was "below" the IP protocol level. The amateur system, however, probably operates at the IP level like some of the more recent combined packet switch/gateways such as the Proteon 4200, Cisco boxes, and so on. Vint
karn@thumper.bellcore.com (Phil R. Karn) (02/02/88)
> the "packet radio" referenced was not the DARPA packet radio but the > amateur packet radio. I don't know how those systems handle the TTL > field... The "amateur Internet" is much like the real Internet -- a mixture of IP gateways and "digipeaters". Digipeaters are single frequency store-and-forward repeaters that operate on the source routing fields in the "AX.25" amateur link level protocol. Since digipeaters do not understand IP, they do not modify TTL fields even though they may introduce considerable delay. Most amateur packet radio channels operate at 1200 bps synchronous, with substantial contention and keyup delays, plus high collision rates due to hidden transmitters. In general, the TCP/IP nodes on the amateur Internet are PCs running my TCP/IP implementation (the "KA9Q" package). This includes end-nodes as well as IP gateways. At present, my code decrements the TTL field by 1 for each pass through a gateway module, including the end hosts. One of the interesting observations to come out of our experiments so far is the interaction between the retransmission algorithms in the TCP (transport) and AX.25 (link) layers. It definitely does *not* pay to try "too hard" at the link layer. If it takes several extra retransmissions to get a packet through, chances are that a TCP retransmission will occur in the meantime and you'll just have to do the same all over again with another copy. It may be worthwhile to allow control over the "beta" constant in TCP, perhaps in combination with the "reliability" bit in the IP header (my gateway code uses this bit to override the per-link default setting as to whether to use link level acknowledgements or not). I think we've shown pretty convincingly, though, that you can't use link level ARQ to sweep fundamental inadequacies in the lower layers under the rug. This is especially true with channel access algorithms. Our experiments are now moving toward multi-frequency full duplex gateways that will eliminate contention and improve channel utilization markedly. Phil
karn@thumper.bellcore.com (Phil R. Karn) (02/02/88)
In article <919@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: > The "amateur Internet" is much like the real Internet -- a mixture of IP > gateways and "digipeaters".... Oops, what I meant to say here was that the amateur network is much like the real Internet in that both consist of a mixture of IP gateways and lower level entities that don't understand IP. The amateur packet radio internet includes its non-IP "digipeaters" in the same way that the "real" Internet includes X.25 packet switches, Ethernet repeaters and bridges. Depending on the specific network configuration, either the IP-level gateways or the subnetwork level components may do the bulk of the work. Phil