>[...] But we do not define exactly what is meant by QOS... Anyway, I have
>always felt (and I think it's in the document someplace) that the
>architecture
> - MUST have the ability to assign 'attributes' to the 'things'
> that make up the net (links, topological-entities, paths, whatever)
> - MUST support multiple paths from A to B,
> - MUST be able to build paths that have different attributes, and
> - therefore the forwarders could select paths based on some "stuff"
> in the packets.
>So it seems to me that this would satisfy Ran's requirement. Yes?
>
>
>
>The other case is when there is only one path (such as an ISP-to-
>single-homed-customer link). In this case, the only thing that can
>be done is to select behavior _internal_ to a router (such as
>which queue to place a packet on).
>
>I claim that this, second, case is not a part of "routing" and is
>therefore not within the scope of the work we're trying to do.
Sounds good - the place where QoS and routing intersect is where you want
to associate specific attributes with a path to a destination and create
edge to edge paths from a source to a destination where this attribute is a
common property of every segment of this path. The inference from this
desire is that there is the assumption that there are multiple paths to the
same destination and that these paths do not all have the same set of
attributes and the choice of which path to use of not mandated by the
network but available as a choice to the edge system. This would tend to
imply that a routing system would need to carry information based on both
the destination and the service attribute(s) that can be associated with a
candidate path to that destination.
The issue to me is whether this property is desireable in a routing system,
and what are the consequences of deploying such a feature. Without doubt
vendors and network operators are fanatically keen of such measures for
obvious reasons, and are quire prepared to walk over vast distances of hot
coals of suspended disbelief to argue the wisdom and urgent need of such
functionality. As to its actual value to the end application and the
ability for an end user to make informed decisions about their
application's likely performance and associated cost when attempting to
grapple with this form of multi-path multi-service network, then its not so
obvious to me that there is sufficient value in this approach to mitigate
the somewhat massive scaling load that this additional routing function
typically requires.
So in the same vein that the outcome of the process of standardization of
OSPF V2 threw out the TOS routing bits, I'm not convinced that Frank's
MUSTs are indeed MUSTs. For me the MUSTS become: "COULD, but there are a
whole set of factors relating to scaling and the dyanmic stability of the
system that we just don't understand which possibly end up indicating that
its not a good thing in any case"
Geoff
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT