Subject: Re: DSR/AODV/& BS Stuff

From: Tom Hello <[email-masked]>
Date: Fri, 12 Jan 2001 20:05:39 -0800 (PST)

Nitin: I don't think you should implement LAR (which 
is not a protocol as you claim) with DSR! You clearly
exhibit some form of political bias. 

Is that related to your MobiHOC conference in some 
way or is that related to your paper acceptance? I
realize you publish things related to DSR and AODV -
clearly you are trying to gather "favor" from those
folks/people. 

Does that explain how you get your papers published in

MOBICOM (and you constantly published there) and
your NSF grants too?? Man.. this is bad...

=====================================================
--- Tom Hello <[email-masked]> wrote:
> Oh you (nitin)... About LAR/LAM - there are many
> flaws
> in location based routing. Your original proposal
> does not take into account connection/signal
> propagation properties, just location which is
> wrong.
> None of LAR/LAM have been implemented and tested
> in real systems. You should do it since you started
> it.
> 
> There is too much BS Stuff in this circle.
> I recall AODV - where the heck is the distance
> vector
> being used here?? That was just a twist from the
> DSDV
> protocol which is a table-driven protocol but
> the authors twisted it to change it to on-demand 
> based. There is just not enough good/properly 
> designed protocols and too much BS stuff and
> politics
> too.
> 
> These people need to wake up...
> 
> 
> --- Nitin H Vaidya <[email-masked]> wrote:
> > 
> >   >> From: Tom Hello <[email-masked]>    
>  
> >  
> >   >> From [email-masked] Fri Dec 22
> > 12:43:48 2000
> >   >> 
> >   >> Li Li wrote:
> >   >> >
> >   >> >In the DSR draft, it says "Although many
> > routing
> >   >> >protocols operate correctly
> >   >> >only over bi-directional links, DSR can
> > successfully
> >   >> >discover and forward
> >   >> >packets over paths that contain
> > uni-directional
> >   >> >links."
> >   >> 
> >   >> I don't believe a single word of it. It was
> not
> >   >> even proven!! The DSR draft constantly copys
> > and
> > 
> > I do not recall if they give a formal proof or
> not,
> > but
> > it seemed to me that DSR could work on
> > unidirectional links.
> > Do you have a counter-example (or a "proof") that
> it
> > does not work?
> > 
> >   ...
> >   >> Also, why you are enhancing DSR and not doing
> > your
> >   >> own protocol? One need not have a paper that
> is
> >   >> DSR compliant to get one's paper accepted!!
> > 
> > Huh !?
> > Enhancing an existing protocol is not necessarily
> a
> > bad
> > thing, be it DSR, AODV, TORA, whatever.
> > 
> 
> > Happy holidays.
> > 
> > - nitin
> > 
> > .
> > hoc/ 
> > 
> > Happy holidays.
> > 
> > - nitin
> > 
> > .
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos - Share your holiday photos online!
> http://photos.yahoo.com/
> .
> u Yahoo!?
> Yahoo! Photos - Share your holiday photos online!
> http://photos.yahoo.com/
> .
> 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---

From: Dave Johnson <[email-masked]>
Date: Fri, 12 Jan 2001 23:37:46 -0600

Tom,

I've resisted replying to your earlier messages, but I think its time
I joined this discussion.  I think your criticism of Nitin's
publications and NSF grants is quite unfair.  If you have evidence of
actual favoritism toward people who base work on DSR or AODV, please
share it with us; otherwise, your accusations are unfounded and
without merit.

In the paritcular case of people basing their work on DSR, let me
assure you that (as the leader of the Monarch Project that designed
DSR) this adds no special "favor" to the work in my opinion.  On the
contrary, if anything, I think this raises the bar with me for such
work, since I care a lot about the protocol and its future and don't
want "bad" work based on top of DSR.  LAR, however, I believe is good
work, for its stated application and purpose of helping to reduce the
overall routing overhead in the environments for which the protocol
was designed.  Nitin has correctly described the protocol's advantages
and limitations.

And while I'm writing a message to you, let me go back to an earlier
message in which you said "The DSR draft constantly copys and adds
methods from other people to be included in theirs, which is
ridiculous."  Perhaps you could explain what you mean by this.  If
there are methods that you believe we have copied from other people,
please identify them and we will appropriately acknowledge them in
future DSR drafts and papers; otherwise, again, your accusations are
unfounded and without merit.

And further, Tom, perhaps you could give the group a little
information aboutl your own background and activities in the area of
ad hoc networking.  You know all of the other people involved in this
discussion -- through our identifiable email addresses and our names
and other contact information on the published Internet-Drafts and
other papers that you criticize.  In contrast, all that you have
identified yourself so far with is a free (and easily anonymous) Yahoo
email account.

					Dave

---

From: Joe Macker <[email-masked]>
Date: Tue, 16 Jan 2001 10:14:20 -0800

Inappropriate postings include:

Unsolicited bulk e-mail Discussion of subjects unrelated to IETF policy, 
meetings, activities, or technical concerns Unprofessional commentary, 
regardless of the general subject.

This is clearly unprofessional commentary beyond the bounds of technical 
concerns.

-Joe

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Jan 2001 09:06:55 -0800

Hello folks,

Two small corrections/comments:

First, AODV is supposed to work over uni-directional
links.  A difficulty arises when a RREP cannot traverse
a unidirectional link from which a RREQ was received,
but there is a mechanism defined in later drafts to
handle that case.  There was some discussion about this
point at the last IETF meeting.

Second,

> vector being used here??

The route table store distance (number of hops)
and vector (next hop) information.  So that's good
enough to fit my definition anyway.  Is there
something more that is needed to be a distance-vector
protocol?

> That was just a twist from the DSDV protocol
> which is a table-driven protocol but the authors
> twisted it to change it to on-demand based.

If one would substitute "revised" instead of "twisted"
I'd be happy to agree.  Oh, heck, I'll agree anyway :-)

Regards,
Charlie P.