Is Best Effort IP Really
Economic?
Dr. Lawrence G. Roberts
IPv6 Newsletter, June 2004
Shortly after I
started the
ARPANET in 1969 a religion somehow was created that “best effort”
packet
routing is the most economic way to forward data in the Internet. This
was
based on the concept that keeping any state information in the routers
would
somehow make them more expensive or un-scaleable. In 1969 this was
true, memory
was so expensive that it would have been foolish to keep any state
information
about a flow (a flow is the sequence of packets that forms a call or
individual
connection, all going between the same two processes). In 1969 the
memory to
keep state information for all the flows in the highest speed port
would have
increased the cost of the port by a factor of ten. Today, in 2004,
although the
port speed has increased from 50 Kb to 10 Gbps and the number of flows
on a
port has increased from 100 to 2M, the memory cost has decreased
sufficiently
faster than the port cost that the memory to keep all the flow state
information
is now only 0.6% of the port cost. Thus, it now is worthwhile to
examine what
benefit keeping this state information would achieve. The graph below
shows
that the cost of flow state memory became economic in the late 1990’s.
Flow state allows
one to
track and control the rate of a flow. Router control of TCP flows has
been
based on the assumption that rate information was not available in the
router
and therefore random discards based on queue length (RED or WRED) have
been the
best technique available. This typically permits at most 40% port
utilization
to insure low packet delays. However, given rate information on each
flow and
measurement of the total port utilization, TCP flows can be rate
controlled by
the router to just fill each port to 80% and not ever build up queuing
delay.
This can be done by discarding packets, as is the practice with
slow-start
today, or it could be achieved with rate feedback to the TCP process so
that no
packets would need to be discarded. Once a series of routers in the
flow path
can negotiate and return the rate they can support a TCP flow,
slow-start can
be bypassed and the sender could jump to the full maximum rate the
network can
support without congestion. Whenever congestion in the network changes,
the
rate can be adjusted, thereby allowing the network to rapidly adjust to
varying
load without having to confuse the sender with discards due to
congestion and
discards due to transmission errors.
This rate
feedback concept
has been introduced into IPv6 in an in-band QoS option field that
negotiates
the TCP rate across the network and returns it to the sender. Each
router can
adjust the rate to whatever rate it can support without congestion.
When the
sender’s TCP process receives the rate feedback, it can immediately
jump to the
agreed rate. From time to time the network may return a different rate,
but the
sender never needs to slow down due to lost packets and only needs to
retransmit those packets truly lost due to transmission failures. Thus,
in one
round trip time (.1 to .5 seconds) TCP can start sending at very high
rates and
thus send a 1 MB web page in less than one second rather than the ten
seconds
typically required today for pages 1/10 the size. The 10:1 improvement
in WWW
access time could dramatically improve productivity. Also, this
technique works
well even when the round trip delay is long as in overseas access or
satellite
use.
The reason this in-band option is
possible with
IPv6 and not with IPv4, is that IPv6 protocol has a flow label that
identifies
the flow even when the packet is encrypted and also IPv6 requires each
router
to act on hop-by-hop options like the QoS option. Thus, as the QoS
request
progresses across the network, each router can adjust the TCP rate to
whatever
rate it can support. This option processing is normally feasible in
IPv4 and
given the important addition of encryption security, even the flow
cannot be
identified without the flow label. The benefit of controlling the flow
rates
not only allows ten times faster TCP operation, but it also permits the
routers
to achieve 80% utilization of the routers and the trunks. This is
because the
combined rate of all flows is known and the port utilization measured,
thereby
allowing much greater control of the accepted load. This 100% increase
in
utilization results from the addition of the additional 0.6% cost for
the flow
state memory, thereby clearly exploding the old religion that flow
state would
increase cost or not scale. On the contrary, it reduces cost by 60% and
permits
full in-band QoS specification including guaranteed rate flows,
precedence,
delay priority and TCP rate feedback.
The end result is
that IPv6
with this new QoS option reduces the cost of IP by at least 2:1,
decreases the
time for WWW page access by 10:1, allows no-loss video and voice
guaranteed
rate flows at any speed, supports emergency services like 911 through
precedence, and virtually eliminates packet loss in the network even
for TCP.
All this is achieved without the routers needing to (or being able to
due to
encryption) peer into levels 4-7 to make a poor guess about the QoS
desired. Thus the actual processing and
cost required for good QoS is actually less with IPv6 then IPv4 and the
result
is far superior.