Subject: Re: [Why am I receiving all your mails....

From: "SEOW LING ONG" <[email-masked]>
Date: Sun, 06 Feb 2000 20:05:01 GMT

Hello,

Whoever your people are.... I seems to be recieveing all your mails 
communicating with each other but I DON'T EVEN KNOW YOU PEOPLE.
I also realise that my email address is not in your communication but the 
true fact is I have been recieving hundreds of your mails in the pass few 
months. Please check your system and make sure I don't recieve them again.

I am getting sick and tired of deleting all these junk mails!

Thanks.

>From: Masataka Ohta <[email-masked]>
>To: [email-masked] (Ping Pan)
>CC: [email-masked], [email-masked], [email-masked], 
>        [email-masked], [email-masked], [email-masked], [email-masked],        
>[email-masked], [email-masked]
>Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource 
>management
>Date: Wed, 19 Jan 0 8:37:47 JST
>
>Ping Pan;
>
> > > hmm - interesting - thouhg i am still not sure why you can't work on
> > > an evolutionary path with RSVP rather than a whole new protocol
> > >
> >
> > We've tried very hard to address the scaling problem with RSVP in the
> > past year or so. Lou Berger, George Swallow, Lixia (and her students)
> > and us have tried to enhance RSVP soft-state properties in various
> > drafts. At this point, I believe RSVP (and its LSP extension) will have
> > no problem whatsoever to handle intra-domain requirements. But RSVP does
> > have the N**2 problem. When you look at the data we had gathered in
> > Section-2 of our draft, any signaling protocol with N**2 property would
> > be difficult work in inter-domain environment.
>
>As I have pointed out in RSVP-related WGs and several research papers,
>RSVP has no scalability problem from the begining.
>
>So, I agree with you that it is very hard (impossible) to solve
>your problem, because the problem does not exist.
>
> > One of the issues in RSVP is the notion of "route-pinning" at PATH
> > processing time. This forces the routers to remember every reservation
> > sender. At RESV processing time, the routers need to map the RESV to the
> > previous PATH.
>
>No. As I pointed it out in some I-D and the INET'97 paper, the solution
>is to route RESV first and let PATH follows the route.
>
>Note that route stabilization is easy that route-pinning is not
>necessary at all.
>
>There are simple reasons why BGP like policy can not be applicable to
>resource reservation. But it seems to me that the topic is to hard
>for you to understand.
>
>                                                         Masataka Ohta
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com