Re: repost from rolc regarding rsvp/atm discussion

[Craig Partridge <[e-mail]>]

    thanks for the explanation, but it doesn't make ANY sense to me.  why
    would a user care if there exists a router from which the services are
    asked from?  the application should ask a particular service from the
    network, not from a router.

Juha:

    Sorry my explanation doesn't make sense -- let me try again.  (And I'll
cross post to ROLC on the grounds that others may also be confused by what
I said).

    Strictly speaking, I shouldn't have said "routers" but "service elements"
which one can think of as anything which accepts IP datagrams on one sides
and spits them out the other side.  So one can think of a MAC layer network
with two hosts attached as a service element, as one host puts IP datagrams
in and the other takes it out.  In short, the INT SERV stuff works just
fine over a single network without any routers.

    Pushing ahead, you point out the application asks for a service from
the network.  From my perspective that's not quite right -- the application
asks *something in the host* (a software library, the OS, whatever --
via what you'd call the API) for a service and that something asks the
*internet layer* which in turn works with the MAC layer.

    The reason I like this model is that there's a lot of complexity in this
process.  For instance, as you know, the same video stream could be described
by hundreds or thousands of different token buckets.  Which description you
choose is likely to depend on local policy and tarriffing issues.  And you
don't want to have to embed tarriff tables in every application.  So something
between (which may just be a library call or a call to the OS) makes
the problem a lot easier.  It also gives you a level of indirection to cope
with things like combining flows.

    And yes, this is all independent of RSVP, ATM, etc.

Craig