Time out. I was finally able to pull up the link. I had to drop the extensions and go directly to real-internet.org, and then select the English version (the site is Japanese).
I'll retract my original interpretation which was both based on a limited snippet and taken out of context.
Here's the entire article. Let's pick it up new, because they are talking about some protocols which I've not come across before, and for good reason: They are only now in the early stages of introducing them. Read below.
FAC
-----------:
from real-internet.org (then you select what is RIC)
or, if you are lucky, directly to:
real-internet.org
RIC (Real Internet Consortium)
We, the RIC consortium, are working on development of
a simple and integrated suite of Internet protocols with real high speed,
real QoS assurance and real multicast with massively parallel
router architecture.
So far, we have specified the following protocols: HQLIP (Hierarchical QoS
Link Information Protocol), MRVP (Multiple Rendez-Vous Point multicast Protocol),
SRSVP (Simple Resource ReserVation Protocol), SS (Service Specification) SURL (Stream URL)
and additional documents on scheduling: CS (Comfortable Service) and multicast
architecture: SM (Static Multicast).
It is widely recognized that, because of the speed limitation
of electric circuit, Tbps or Pbps routers can be constructed
only with massively parallel architecture with a lot of elementary
routers combined by a high speed interconnection backbone.
On the other hand, it is widely misunderstood that fine grain
QoS assurance of individual flows is impossible, because, at
the high speed backbone of the Internet, there are so many flows
that signaling of the flows and routing (including policing
and fair queuing) of packets of the flows do not scale.
It is not widely understood that the backbone scalability problems
of QoS assurance is solved by massively parallel nature of
high speed routers.
As a result, people in conventional standardization forum such
as ISO, ITU and IETF are, in vain, trying to produce complex protocols to
aggregate flows to reduce the complexity. However,
it is easy to prove that such aggregation is impossible at
least with multicast or QoS routed flows. Thus, in some IETF WG,
QoS assurance is finally given up and CoS assurance, which is not useful
for most applications, which is often obfuscated by the fallacy of
calling CoS QoS, is pursued.
Instead, we solve the scalability problem of real QoS assurance
in a simple, straight forward fashion. With a properly architected
massively parallel router, signaling and routing load can be
distributed evenly over elementary routers.
As flows reserves certain bandwidth, the number of flows in a link
is at most the bandwidth of the link divided by the bandwidth of
flows and proportional to the bandwidth of the link.
Thus, problems of scalability proportional to the number of flows
are scalably solved by elementary routers the number of which
is proportional to the speed of the link or the number of flows
in the link.
As multicast routing table entries can not be aggregated, multicast
communication is a resource (routing table entry) reserving one.
Moreover, bandwidth can not be negotiated between receivers with
different available bandwidth, the bandwidth can only be determined
by the sender, transport of which requires resource (bandwidth) reservation.
SRSVP combined with MRVP signals resource (including bandwidth and routing table
entries) reservation request for unicast and multicast communication.
With resource reserved multicast, scalable floor control mechanism to disable
intruders consume the reserved resource, is essential
that multicast protocol use authorized root such as a rendez-vous point of shared tree PIM.
SRSVP is based on RSVP but simplified a lot to support PIM-like multicast model
only and to use TCP between adjacent routers for reliable state
maintenance. MRVP specifies communication protocol between multiple rendez-vous
points for fault tolerant multicast.
Many multicast routing protocols broadcast or flood information on individual multicast
groups in a certain domain expecting some interdomain multicast protocols can solve
the scalability problem of flooding. However, flooding of information by the network
is to make the network unnecessarily intelligent, which is against the end to end
principle of the Internet. According to the end to end principle, it is end systems
responsibility to get necessary information on multicast session and SM use DNS to let end
systems and routers at branches of multicast trees authoritatively know the locations
of rendez-vous points. By allowing administrators of individual multicast groups control
the locations of rendez-vous points, the rendez-vous points can be located near
the expected locations of source. Then, it is not necessary to use source centered tree,
which is known to cause a serious scalability problem.
Other session information such as required bandwidth, common
both to uni- and multi-cast, should be known by end systems through some end to end
mechanism such as URL and be propagated to intermediate routers through a signaling
protocol. Session announcement through some broadcast or multicast channel, such as
that used by SAP, does not scale.
The remaining commonly seen misunderstandings are that
there are still problems of QoS assurance with scalability
problems.
One example is that scheduling of QoS assured flows had needed sorting
and had had temporal computational complexity proportional to the
logarithm of the number of flows. The misunderstanding is originated
from ATM and imported to IETF Intserve model as a guaranteed service model.
However, by carefully analyzing the nature of QoS assurance and Internet
traffic (for example, 100% delay guarantee is meaningless when 100% reachability
is not (can not be) guaranteed), it is possible to construct a traffic model
(CS, Comfortable Service) and scheduling algorithm (PPQ, Policed Priority Queuing)
of QoS assurance with a complexity proportional to the number of flows.
With CS, it is not meaningful that different receivers request different bandwidth,
which is one of the reason why SRSVP is simple.
The other example is that QoS routing were an NP (Non-deterministic Polynomial)
hard problem. While QoS assurance of both delay and jitter is NP hard, such assurance
is not meaningful with the dynamic Internet where rerouting may drastically change
the current delay, in which case, the lower bound of delay can be given only by the distance
between end points divided by the speed of light, which is invariant regardless of the
network status. Thus, we are targeted to assure maximum delay (including jitter) only.
Finally, we seriously consider policy issues. While policies of individual ISPs to
choose the backbone is considered essential with the current best effort flatly rated
Internet important, the same logic is not applicable to the QoS assured communication
over the Internet. When subscribers are charged proportional to their use, which is
the charging policy for QoS assured communication, ISPs want
to enclose their users and users' traffic within them to maximize their revenue,
which violates anti-trust laws. For QoS assured communication, it is subscribers
which control the policy. ISPs should make their identities and charging policy
and subscribers should choose appropriate route based on their policy.
In most cases, subscribers policy will be as simple as "use the most inexpensive
route satisfying the required QoS" but subscribers may specify explicit routes.
Note that with multicast, only the sender side of the subscribers can have their
own detailed policy, because receivers with conflicting policies can not share a
single tree. HQLIP is the routing protocol which announces link
information such as available QoS and charge of the link with 256 levels of
hierarchy. BGP or distance vector based routing, with which best route is selected
by the network according to the "best route" defined by providers' policy is
unusable for QoS assured communication.
HQLIP is designed with quick convergence of routes in mind to enable quick
layer 3 restoration.
We, the RIC consortium, have successfully developed a simple protocol suite of
the next generation Internet for QoS assurance, multicast, session announcement,
charging, routing, policy and layer 3 restoration, only because we attempted to solve
all the interrelated problems at once by an integrated protocol suite, which makes
it unnecessary to make some protocol overly generic.
We are now at the stage of final polishing up of protocols and reference
implementations. Your comments and inputs are welcome. |
