a few commetns in response to Yakovs note of 4/6

[Deborah Estrin <[e-mail]>]

Following are points of Yakovs that I DISagree with. There are
actually many questions and issues that Yakov raises  that i think are
very important and that I AGREE with, but it is more importnat (fun)
to talk about the things we dont agree on :} 

As you read the following pls keep in mind three biases of mine. I
decided it is better to put them right up front and out in the open:
a) I am in favor of unified routing archiecture eventually
b) I am also in favor of getting experimental experience with Source
Demand Routing right now so that we get it right for unified. I see
SDR as an essential part of unified.
c) I am not particularly in favor of going to draft standard right now; i
think it should be experimental standard. 

Now to the fun stuff... The okrder follows the order of yakovs last
set of comments. 

1. I believe i could find a quote in a paper by Dr. Rekhter and his
illustrious colleagues :}  that explains why you need/should have
source demand routing to support efficient, fine-grain, unpredictable,
or source-specific policies. So I am confused why you keep questioning
"Marthas Motives" for wanting to test a protocol that is a first
attempt at source demand routing.

2. your complaint about idpr being inefficient for small number of
data messages is also true for TCP....if your point is that there
should be an option to heave explicit source route instead of
insisiting on setup, then i expect if you just say that everyone would
agree!!! That does not mean that you never want to do setup and that
it is not worth experimenting with a first version of a setup protocol

3. why are you nitpicking about this issue of defining what a backbone
or transit is. what is the issue. ? 

4. Of course supporing new types of service requires more than just
changes to routing. but when the whole networking community talks
about tos, they talk about the piece of the problem they ar eworking
on. And they dont give numberrs predicitng what percentage of the
hosts or traffic will use it. Why is that kind of crykstal ball needed
here? the whole world agrees that we want to support other QOSs so
this is one component of that problem.

Your point is well taken that we MUST make it clear we are not doing
optimal routing or globally distributing load information; but your
other complaints seem overboard to me. 

Anyway, even in IDRP you dont go into discussing all the other network
layer and transport layer services needed to support different QOS and
you do mention othe rQOS support...

5. IDPR does NOT assume a particulakr charging model. The archiecture
leaves room for charging model info to be distributed in updates when
standard syntax and semantics is defined for various charging models,
then this can be taken into account in route computaton. I thnk the
same is true for IDRP

6. the benefits of using IDPR or SDR for vanilla tos is to get through
restricitive networks that would otherwise not make their routes
avaialble. ie those that express source-specific policies.

7. Yo uhave seen one paper that tries to quantify state requirements
in routers (it will appear in Infocom 92); i can send it to anyone
else who wants to see it. It all depends on traffic of course, and
some on topology of course. 

8. All of the network schemes that will offer QOS guaranteees or
reservation service accommodate datagram traffic as well. I can point
you to alot of work in this area and i dont think it needs any
justificatoin here. 


9. Obviously I agree with the notion that ultimately we dont run IDPR
as the only interdomain routing protocol. But I dont see why that
means we stop experimenting with IDPR as our current prototype of ak
source demand routing protocol. Then by the time we go to impleent and
finalize design of SDR compontnt of unified, we learn from that
experience. 

There is BGP and IDRP and i see the justificatoin being similar altho
of course the urgency for BGP to replace EGP was the primary
compelling issue there and so it is a poor analogy that Yakov eill
undoubtedly point out :}

10.  IDPR is not doing load sensitive routing (yet :}) It is true that
I (with Lixia Zhang and Lee Breslau) are working on possibilities for
supporting some laod sensitive routing with in the context of source
demand routin ut this is NOT what IDPR is doing. Innformation
distrbuted is just about configured capabilities and whati s up or
down, not about load levels.

11. Do you have a sampel study of stability for IDRP that we could
model ka study of IDPR stability after?

12. I think that multimedia communications/essions will change the
fact that now we have one session per workstation pair in general. but
that is not critical to the argument, just responding to one of your
later points. 

13. Finally, as i said above and earlier to some on this list,  i sort
of agree with your last point about going to 
standards now, although perhaps not as vehemently...:}

I better send this message before I chicken out... :} Sorry for all
the typos. 

D.