IDPR as a Proposed Standard

[[e-mail]]

	The following is an attempt to summarize certain issues that
	surfaces during the recent exchange on IDPR mailing list.
	
	To avoid misinterpretation of my comments I'd like to
	say up front that for those, who believe that I am totally against
	source demand routing, I would suggest to read the
	internet draft "draft-ietf-bgp-unirouting-00.txt".
	While reading it, please note that I was one of the
	authors. If that still would not change your belief, please
	send me an e-mail, and I'll attempt to resolve this on
	an individual basis (either by phone or via e-mail).
	

	1. Hop-by-hop vs source-specified message forwarding.

	There is a fair degree of confusion between these two
	concepts.

	First of all, observe that packet forwarding in IDPR is
	hop-by-hop. So, hop-by-hop is a misleading terminology.  To be
	more precise we'll talk about IDPR vs existing Internet
	forwarding.  The essential distinction between IDPR and
	the existing Internet forwarding is that with IDPR the
	forwarding information is installed by the source domain on all
	the participating routers along the path. In the existing
	Internet forwarding each router installs its own forwarding
	information based on the computation over the routing
	information.

	Both with IDPR and with the existing Internet forwarding each
	node forwards packets along routes that the source computes.
	The essential distinction is the amount of information that the
	source can use for the route computation. With the existing
	Internet forwarding the choices are limited by the ones offered
	by the adjacent domains. Thus, a route computed by source is
	consistent with the routes computed by other nodes along the
	path. With IDPR a domain has global topology information and
	global transit policies information.  Potentially, that may
	have direct implications on the number of choices available to
	the source. These potentials need to be judged carefully
	against the volume of the information that needs to be handled,
	and the amount of computation required to process the
	information. In fact, it was acknowledged that the "Internet
	routing information may be too large to be maintained by any
	one router".  These potentials also need to be judged against
	reality to see how important they are with respect to the
	existing Internet.

	Statements that IDPR-style forwarding is "the only way to gain
	forwarding control required for true policy-based routing" need
	to be substantiated.

	Likewise, statements that the existing Internet forwarding
	"does not provide assurance for traffic sources that their
	traffic travels over the routes they select" needs to be
	substantiated.


	2. Introduction of a new network layer protocol to accommodate
	inter-domain forwarding.

	IDPR introduced a new network layer protocol designed
	specifically to accommodate IDPR style forwarding. It was
	justified on the basis of the assertion that there is no
	mechanism available for efficient source-specified forwarding.

	There are two basic techniques to accommodate source-specified
	forwarding: path setup and source route per packet.  Putting
	aside for a moment the issue of path setup vs source route per
	packet, let's just focus on the path setup technique.  In its
	essence this technique allows a source domain to install
	forwarding table entries on all the participating routers along
	the path. That implies a globally known (among the
	participating routers) rules about how to map information
	present in a packet to the information present in the
	forwarding tables. IDPR uses path ID as a handle that provides
	such mapping. Since current IP has no notion of path ID IDPR
	needs to introduce a new network layer protocol that can carry
	this information (path ID) along with the original packet.

	However, we need to observe that there are other alternatives
	to provide the required mapping between an IP packet and the
  entry in the forwarding table. For example, to provide
	mapping with the desired granularity one may use other than the
	destination address information present in a packet, like
	source address, ToS, etc... Since such an alternative would not
	require introduction of a new network layer protocol it needs
	to be evaluated as a preferable technique for path setup
	source-specified forwarding, unless it can be shown that such
	an approach is deficient (as compared to the one taken now by
	IDPR).
	
	3. Path setup vs source route per packet.

	Source-specified forwarding can be accomplished either via
	path setup technique or by specifying explicit source route
	in each packet. The source route needs not be strict (in IP sense),
	but may just list domains that the packet has to traverse.
	One of the limitations of the new network layer protocol
	introduced by IDPR is that it does not support source route
	form of the source-specified forwarding. In fact, as was pointed out
	"IDPR deprecated any other source-specified forwarding
	than the one accomplished via path setup."

	That seems highly unfortunate,  since path setup, which was
	used as a justification for the new network layer protocol,
	may be accommodated without introducing such protocol (see above),
	while accommodating source route per packet which may benefit from
	introducing a new network layer protocol, was ruled out by IDPR.

	Some may argue about whether the overhead of path setup can
	justify its existence.  It was asserted that "if path persist
	for long period of time, then the initial overhead of path
	setup is not significant compared to the life of the path".  A
	corollary of this is that if a path does not persist for long
	period of time, then the initial overhead of path setup is
	significant.  Path setup was justified on the based of
	efficiency for forwarding large number of messages.  As was
	pointed out, there seems to be no experimental evidence or
	rationale based on the traffic characteristics within the
	Internet for making such justification applicable.  Moreover,
	detailed analysis by Tony Li did not indicate significant
	performance advantages of path setup vs source route per
	packet.

	Unless someone would be able to demonstrate that path setup
	has clear advantages over source route per packet, in view
	of the complexity and overhead associated with path setup the
	decision of going with path setup seems to be ill-justified.
	This is especially true given our previous comments on the
	path setup as a justification for introduction of a new network
	layer protocol.

	
	4. Support for applications with strict requirements on delay,
	delivery, bandwidth.

	One of the motivations for IDPR was "to ensure that sources
	have access to routes that provide the services that their
	applications require".  However, it was also acknowledged that
	IDPR, on its own, is not capable of providing such services and
	that "to guarantee services, we need to be able to reserve
	resources and to control traffic flow rates". It was also
	acknowledged that the latter are not part of IDPR.

	It was correctly asserted that "service offerings must be
	accompanied by mechanisms to take advantage of these
	offerings." It was also asserted that "in the near term ...
	applications that require bandwidth reservation will become
	prevalent." For such applications "the ability to generate and
	use routes that supply the requested bandwidth and to manage
	the traffic flows over such routes will be the responsibility
	of Internet routing and flow control mechanisms". That implies
	the presence of the overall architecture to support such
	services.

	Thus, IDPR needs to be integrated as an essential component of
	such architecture that deals with the Internet that provides
	new functionality, like resource reservation, control traffic
	flow, etc...  An attempt to deal with these issues in
	isolation, solely within the scope of IDPR, without clearly
	defined overall architecture is likely to be a step in a wrong
	direction.  It may lead us to a situation where different
	groups, on their own, develop solutions to different components
	of the architecture in such a way, that the combination of
	these solutions would not interoperate, thus making the whole
	effort useless.


	5. Support for charging.

	It was asserted that IDPR provides "route selection ...
	according to monetary cost..".  At the same time it was
	asserted that "IDPR does not assume a particular charging
	model".  It "leaves room for charging model info to be
	distributed in updates".  Furthermore, it was stated that "when
	standard syntax and semantics is defined for various charging
	models, then this can be taken into account in route
	computation."

	Providing meaningful support for charging requires
	well-defined architecture (this is necessary, but not
	sufficient). Support for charging in inter-domain routing needs
	to be part of such architecture. An attempt to deal with
	charging in isolation within IDPR, without clearly defined
	overall charging architecture is likely to be a step in a wrong
	direction.  Hopes that "when standard syntax and semantics is
	defined for various charging models, then this can be taken
	into account in route computation.." are misleading. They
	attempt to assure us, that when the overall architecture will
	be defined IDPR would be capable of supporting it. However, as
	was pointed out by Tony Li, such support may require to change
	all the IDPR participants throughout the Internet. That may
	not only be undesirable, but impossible.


	
	5. Impact on existing Internet.

	It was acknowledged that there are no stringent delay or bandwidth
	requirements defined for such applications as e-mail, FTP, Telnet, NFS.
	Thus, the ability of IDPR to ensure that sources have access to
	routes that provide the services that their applications require
	becomes irrelevant for the absolute majority of the current Internet
	applications. While it was suggested that "such requirement could be
	defined", one may wonder how that would relate to a famous paradigm
	of "a solution looking for a problem".

	It was asserted that for applications like FTP, Telnet and e-mail
	presence of IDPR is not going have any noticeable positive impact.

	While it was also asserted that "in the near term ...
	applications that require bandwidth reservation will become
	prevalent." there need to be some factual evidence to support
	such an assertion.

	6. On standardization.
	
	There are still quite a few questions that were posed recently,
	but have not yet been answered.  I think that to make an intelligent
	judgement on the subject of standardization of IDPR we need to answer all
	these questions (and not just a subset of them).

Yakov Rekhter