On Fri, 30 Nov 2001, batz wrote:
Indeed. The notion of "hopcount" is objectively meaningless. You can count hops by physical wires, data segments, network hops, AS's or combinations of each (MPLS, GRE, PPP etc).
Actually, not. The hops which "count" are places where traffic flows are stochastically multiplexed. Since every such place has to have buffers of size comparable to end-to-end RTT * bandwidth (to give enough time for TCP flow control to react), the maximal packet delay is Nhops*RTT. Note this does not say what the median variable latency (fixed latency is the signal propagation time) is going to be because it depends on probability of multiple congestions along the path. If congestion events are independent, the result isn't that bad (with long-lived congestion probability of 50% the median variable latency is 2*RTT). Unfortunately, this assumption is not likely to be realistic. I.e. in the "aggregation tree" networks (like the most modern backbones which aggregate outgoing exterior traffic at multiple points, where every aggregation point reduces the total egress bandwith), the congestion is likely to occure simultaneously at many aggregation points along the path. The way to combat variable latency is to reduce the number of hops. This effectively means either creation of meshes of fixed bit-rate circuits (which is way way way ugly because of routing scalability issues), or reducing the number of aggregators along the path by reducing the number of routers. The simplest way to do that is to replace router clusters with large parallel routers featuring non-blocking switching fabrics. Note that non-CBR virtual-circuit techniques (tunnels, MPLS, non-CBR ATM, FR, X.25 etc) don't do anything to reduce the _real_ hopcount; they simply obscure it. --vadim