More comments on comments on response to comments on IDPR draft

[Gene Tsudik <[e-mail]>]

Yakov makes the following comment:

        Can you provide any technical details that would elaborate on why
        "hop-by-hop message forwarding does not provide this assurance" ?
        Likewise, would you please elaborate more on why source-specified
        forwarding is "the only way to gain the forwarding control required
        to true policy-based routing".

Can you please clarify what you mean by HbH forwarding?
Is IP Loose Source Routing HbH?
My interpretation of 'true' HbH is when a packet includes no explicit
information about a route that it must take. (It may, however, include some
ToS-type parameters).
In a more loose interpretation HbH can be taken to mean any type of packet
forwarding where the route is not installed in the intervening gateways.

Onwards...

        Martha:
        -------
        >No, there are two motivations for IDPR.  This first is to ensure that
        >transit domains have control over which traffic flows use their
        >resources.  The second is ensure that sources have access to routes
        >that provide the services that their applications require.

I see three, not two motivations for IDPR. The third one is to ensure that a
domain (AD) has access to routes that conform its POLICY. This includes
route selection policies (e.g., this AD is preferred, that AD is off-limits,
etc.).

        Yakov:
        -----
        Let's separate these two motivations. Do you imply that IDPR
        is THE ONLY way to provide such control over the transit traffic ?
        That is, that if a transit domain wants to have control
        over which traffic flows use it, it has to use IDPR ?

I see (and sense) no such implication in Martha's statement.

        The second objective, providing the services that their applications
        require,assumes AT LEAST that the applications are capable of expressing
        their service requirements. Does that mean that the major customers
        of IDPR are such applications ? Does ability to express service
        requirements by an application imply host modifications ?

The major customers are not just the applications but the stub domains
administrations as well. Service requirements don't necessarily require
host modifications. The encapsulating router (PG) may, in the process of
obtaining a PR for the application flow, obtain the 'generic' service
requirements for a given application 'flow'. One way to do this is
by de-composing the application packet (the one that triggers PR setup)
and figuring out the particular application, e.g., telnet, ftp.

        Martha:
        ------
        >I cannot predict the number of users that will need to run these
        >applications at any given time in the future.  As more services are
        >offered, more users will be able to run applications that require
        >these services.  In turn, this may stimulate more requirements for
        >such applications.

        Yakov:
        -----
        What I've been trying to get at is what is the expected clientele
        of IDPR in terms of percentage of the total user population. Seems,
        like you have no answer to this.

It seems that you are trying to assess the expected IDPR clientele as of
today while IDPR is (IMHO) aimed at the future (circa 3-5 years from now).

        >Also, in section 2.3, I talked about moving the route computation
        >function to a route server rather than keeping it in the policy
        >gateways, in order to reduce the computational load on the policy
        >gateways.

        That brings another interesting issue. How long does it
        take to compute a route, and what is going to happen with
        the IP packets to be forwarded along that route, while the route is
        being computed ?

Here are some old (February 91) measurements of PR setup overhead:

# of PG hops      | 2   |  3  |  4  |  5  |
------------------|-----|-----|-----|-----|
Per-hop overhead  | 50  | 57  |  54 |  58 |
Route computation | 20  | 20  |  30 |  30 |  <-----------------
Setup overhead    | 50  | 170 | 215 | 290 |
Total overhead    | 70  | 190 | 245 | 320 |

The number are in msecs. Note that '# of hops' refers to PGs, not ADs.
A mock 'internet' of 5 ADs was used (the topology was kite-like).
Deborah Estrin may have fresher measurements from newer, improved
IDPR setup/route synthesis.


        I think that your statement needs a bit more support. For example,
        what is the meaning of "perform well" ? Is this an absolute or
        a relative statement ? Some of the problems (but not all of them)
        associated with IDPR were articulated in the paper on Unified Routing
        Architecture written by Deborah Estrin,
        Steve Hotz, and myself. Do you think that the problems articulated
        in the paper are not real ? Or do you think that IDPR
        "will perform well", regardless of the problems stated in the paper ?

Do you have any measurements to support your claim that the problems
you (et al) mention in that paper are going to bog down IDPR :-) ????
If not, these problems amount to mere speculation.

        I think there are few things that are QUITE SPECIAL about
        IDPR that are likely to have direct performance implications.
        Specifically, its rigidity with respect to the forwarding granularity,
        where the granularity is of a single source/destination domain pair,
        unconstrained flooding of routing information that may be of
        no interest to some of the participants, and lack of ability
        to perform information aggregation/abstraction.

How do you support the above claims?

        Connecting two adjacent domains by multiple policy gateways may be a
        nice suggestion, but it does not correspond to the existing
        practice. While you are saying that "domain administrators are free
        to choose how much policy gateway redundancy their domains support",
        such freedom of choice has DIRECT implications on the validity
        of one of your assumptions.
        All that brings me to my previous observation, that the assumptions
        and the implications of violating the assumptions should be stated
        explicitly.

Again, IDPR is not so much aimed at the existing but at the future Internet.
So, basing your argument on 'existing practice' is not valid if you agree
that increasing commercialization will result in drastic changes.

        >> Conceptually this sounds fine, but I wonder how important this
        >> feature is in practice. I heard several comments that suggest that
        >> if there is a traffic between domains A and B, then the average
        >> number of hosts involved in this traffic is equal to 2 (one source
        >> and one destination). If, indeed, this is the case, then it does not         >> matter whether "many different traffic
flows may use
        >> policy... and the same path", since on average there will be only
        >> ONE traffic flow.
        >
        >The feature is there as one of many that are meant to keep the size of
        >IDPR databases "manageable".  I also do not know how often it will be
        >used.  However, I can imagine circumstances under which it would be
        >useful, for example, several people on different hosts in a given
        >domain simultaneously accessing a service provided in another domain.
        >An an example, when a new RFC is announced, several people on
        >different hosts in the same domain may simultaneously go to the same
        >RFC repository (in a different domain) in order to extract a copy.
        >Here one path would clearly be a savings.

        Here we are dealing with a situation when on the one hand
        you "do not known how often it will be used", but on the
        other hand empirical data shows that the likelyhood
        of using this feature tends to 0. I think the empirical
        data should be taken as a very strong hint to protocol designers,
        so that the protocol would not be overburden with features
        that need to be implemented by everybody, but whose utility
        tends to 0.

I'd like to see this empirical data if possible. So far, all you offered is
the statement which starts with
"I heard several comments that suggest that..."

In the summer/fall of 90 when the first phase of IDPR development was going on
there were three main development sites: BBN, SAIC and USC (listed in
alphabetical order...). There was very frequent interaction between the sites:
code (ftp) transfers, mail, telnet (and telephone as well). A lot of this
communication took place simultaneously.
Had IDPR been available at the time, I believe life would've been easier.

Gene