RE: requirements sub-group draft

From: Piet Van Mieghem (P.VanMieghem@ITS.TUDelft.NL)
Date: Fri Dec 14 2001 - 07:35:40 EST


Hello,

Although very powerful, the hop-by-hop forwarding principle becomes
problematic in
the field of QoS provisioning (e.g. QoS Routing or constraint based
routing).

Perhaps and just as information, I may point to a recent article of us

Van Mieghem, P., H. De Neve and F. Kuipers, 2001,
"Hop-by-hop Quality of Service Routing",
Computer Networks, vol. 37. No 3-4, pp. 407-423.

where we show that even with an exact QoS routing algorithm, end-to-end
constraints
cannot be guaranteed in IPv4 nor IPv6 (unless other features will be
included),

Piet Van Mieghem
Delft University of Technology.

> I agree with Vince here. In fact, hop-by-hop forwarding
> not only affects the set of implementable policies, but
> also implicitly constrains the set of solutions.
>
> This question has actually been brought up at the RRG
> meeting today, and my opinion is that the requirements
> should not limit the forwarding model, but should
> require support for IPv4 and today IPv6 forwarding models.
>
> Which scheme is used to forward packets and setup the
> forwarding state in a specific architecture is a separate
> issue.
>
> --
> Alex Zinin
>
> Thursday, December 13, 2001, 1:15:57 PM, David Meyer wrote:
>
> > I didn't see any comment on this question. Did I miss it?
>
> > Dave
>
> > On Thu, Dec 13, 2001 at 08:42:19AM -0800, Vince Fuller wrote:
> >>> > > 3.9 Rich Policy
> >>> ...
> >>> >
> >>> > One of the problems with this whole area is that I've attempted
> >>> > to come up with a good, useful, crisp, definition of policy
> >>> > that covers what people are trying to do today with 'policy'.
> >>> > Unfortunately, policy is one of those N! things -- get N people
> >>> > in a room and you get N! definitions of policy. The lack of
> >>> > specificity and crispness of this section may be, I fear,
> >>> > a reflection of similar lacks in deployed networks. The
> >>> > only real requirement might be "operators have to be able
> >>> > to reach in and diddle with things"...
> >>>
> >>> One question: is the next-generation routing system
> constrained to preserve
> >>> the pure hop-by-hop forwarding model that we've all grown to
> know and love?
> >>> I've read through section 3.9 of the draft so far between
> IETF sessions and
> >>> don't see anything that states that thus far.
> >>>
> >>> Why is this question relavent? Because it directly affects the set of
> >>> policies that can be supported and how those policies are applied. On
> >>> today's Internet, "policy" is primarily about setting the
> next hops that
> >>> traffic uses when it exits a particular domain, with
> brute-force methods
> >>> used to try and engineer end-to-end paths on a per-prefix granularity.
> >>> But this isn't really what providers of edge or transit
> services really
> >>> want; they want to be able to specify how traffic flows to
> the customers
> >>> of their service - those who pay more should get better
> service. In today's
> >>> world, the mapping between what the routing system can
> deliver and what
> >>> the services that ride on top of that system would like to
> see don't match
> >>> well at all, which is why horrible, non-scalable kludges such as more-
> >>> specific route propagation are used in the name of "traffic
> engineering".
> >>>
> >>> Is it within the scope of the next-generation routing system
> to solve this
> >>> problem or does that properly belong at layer-4 or above
> (which, I would
> >>> argue, is the only place that it can scalably be addressed,
> no pun intended,
> >>> today)?
> >>>
> >>> --Vince
>
>



This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT