Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix

From: Greg Daley <[email-masked]>
Date: Fri, 22 Jul 2005 23:03:05 +1000

Hi JinHyeock,

I'm not added much, but this time, not removed much
either.

----- Original Message -----
From: JinHyeock Choi <[email-masked]>
Date: Friday, July 22, 2005 6:33 pm
Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. 
LandmarkPrefix
> Greg
> 
> > I think there are two or three related threads:
> > 
> > Complete RA Polished
> > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-03/msg00157.html
> > 
> > Complete RA Re-polished
> > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00009.html
> > 
> > LinkID Polished
> > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00097.html
> > and
> > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/threads.html
> > 
> > It's good to know that there's been so much work on this (and
> > that everyone can read it).
> 
> It will be nice if the above threads are of help. 
> 
> > There were a lot of differences between individual schemes
> > as portrayed before (in April) and now though.  This may
> > affect the way prefix addition or subtraction works.
> 
> Actually the main changes results from the synchronization
> difficulties. 
> 
> > Given the individual current schemes though, let's try to 
> characterise> the effects of addition or substraction of prefixes 
> on each protocol
> > as configured today.
> > 
> > Does that sound reasonable?
> > 
> > I guess that if the state + processing requirements for
> > Landmark/CompleteRA and LinkID are comparable (which I've
> > indicated may be the case), implementation experiences are
> > qualitative, and in the normal case
> > (and non-DNA case) all schemes act sensibly, the
> > main issues will probably be:
> > 
> > * Synchronization/How the schemes react to change of prefixes.
> > 
> > * Packet Sizes
> > 
> > Does this sound like the right criteria to compare
> > the schemes on?
> 
> It's my opinion that just the above two are too narrow a criteria,
> (though I agree that both of them good). I think other criteria 
> such 
> as 'complexity (as Jak mentioned)' need to be considered. Kindly 
> allow me some time to contemplate other criteria. 

Computational/Storage Complexity is simple to calculate.

Comparison of text or implementation LOCs doesn't help unless
direct comparison of complete schemes is possible though.

Please consider criteria though. We can work on the simple comparisons
first if need be.

> > There may not be a clear winner with any of these, and
> > it may be that the WG just chooses a particular
> > scheme it likes.
> 
> ok. 
> 
> > The comparison is likely to help with forming that opinion,
> > and may actually highlight a winner.
> > 
> > Should we go ahead?
> 
> I think the comparison list is of help. 
> 
> > It may mean some in-depth description of how the schemes
> > currently handle change (which may take some discussion).
> > 
> > I think that we need to compare packet sizes for:
> > 
> > RS/RA exchange for each scheme (or set of schemes) as described
> >       in current drafts.
> 
> I think we should compare the general bandwidth consumption 
> between two schemes (including unsolicited RAs). 

Oh Yes:   I guess that the LinkID and CompleteRA schemes
consume additional bandwidth with ongoing advertisements,
so it's relevant.

Brett had done some work on that previously for the early DT work,
so we may see if it's still applicable

I'll be travelling over the weekend, so that may slow things down.
Greg

---

From: JinHyeock Choi <[email-masked]>
Date: Sat, 23 Jul 2005 12:19:41 +0900

Dear Greg

> Please consider criteria though. We can work on the simple comparisons

I think that comparison needs to be made in whole aspect of schemes 
so that we can properly contemplate pro & con. Complexity may be 
a difficult one to measure (in number) but nevertheless an important factor
just like 'robustness'. 

> I'll be travelling over the weekend, so that may slow things down.

I wish you have a nice trip. 

Best Regards

JinHyeock