Subject: Re: [Roll] multicast DAO

From: Philip Levis <[email-masked]>
Date: Tue, 1 Dec 2009 09:25:48 -0800

On Nov 30, 2009, at 11:39 PM, JP Vasseur wrote:

>>
>
> I do think so. It makes little sense to remove something just  
> because it makes it more simpler.

It makes tremendous sense! Remember these are resource-constrained  
devices. 100 bytes of code can make the difference between price points.

> Multicast DAO does help to come up with shorter path, which is quite  
> important for P2P and the level of complexity is close to 0.

Given the current mandate of "simplify," it seems to me like we should  
remove it, then add it in later if there's strong evidence of its  
benefit. It addresses a narrow case.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Dec 2009 19:00:51 +0100

> devices. 100 bytes of code can make the difference between price  

Is it how it cost to implement it ? I do not think so.

>> Multicast DAO does help to come up with shorter path, which is  
>> quite important for P2P and the level of complexity is close to 0.
>
> Given the current mandate of "simplify," it seems to me like we  
> should remove it, then add it in later if there's strong evidence of  
> its benefit. It addresses a narrow case.
>

Well remember that you also told me that DAO packing was a last digit  
optimization ;-) I'l come back soon with numbers showing that we also  
need to be careful when removing something that it does not break a  
useful functionality. As far as mcast DAO is concerned, let me provide  
figures on how much of improvment it provides in term of P2P path  
quality. So I would suggest to keep for the time being, unless you  
show that it adds so much complexity ...

JP.

> Phil
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Thu, 3 Dec 2009 15:42:35 -0800

On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote:

>> Date: Wed, 25 Nov 2009 10:43:41 +0100
>> From: "Julien Abeille (jabeille)" <[email-masked]>
>
>>> From: Philip Levis [mailto:[email-masked]]
>>> Sent: vendredi 20 novembre 2009 19:31
>>>
>>> Point-to-point communication between nodes is needed by some
>>> applications. Section 5.2.2 of
>>> draft-ietf-roll-building-routing-reqs-07:
>>>
>>> "A network device MUST be able to communicate in a
>>> point-to-point manner with any other device on the network."
>>
>> Sure, and DAOs (whether stored only at root are not) solve this  
>> issue.
>> May not be the most efficient, but the sceanrios multicast DAOs solve
>> are so limited that we will end up with 10 solutions for 10  
>> scenarios if
>> we go that path.
>>
>> I would personaly drop multicast DAOs
>
> I agree.  As we have done with unicasts, we need to look
> carefully at the multicast requirements and find ways to
> solve the easy and/or common cases first.  I do not think
> that there is a workable one-size-fits-all multicast
> solution.

Richard and I discussed this further: turns out he was  
misunderstanding the case I was describing. Based on the fact that  
many application domains require point-to-point routing and the  
expectation is many networks will be at most a few hops across, there  
seems to be some consensus that keeping multicast DAOs in is  
worthwhile. JP will have some results indicating how much complexity  
they might add to an implementation: his experience is not much.

So the current resolution is to keep multicast DAOs in, as the belief  
is the use case described originally by Julien is an important enough  
optimization to warrant their inclusion.

Phil

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 7 Dec 2009 15:37:18 +0100

Agreed.
Julien

> -----Original Message-----
> Sent: vendredi 4 décembre 2009 00:43
> To: Richard Kelsey
> Cc: Julien Abeille (jabeille); [email-masked]
> Subject: Re: [Roll] multicast DAO
> 
> 
> >>> "A network device MUST be able to communicate in a point-to-point 
> >>> manner with any other device on the network."
> >>
> >> are so limited that we will end up with 10 solutions for 
> 10 scenarios 
> >> if we go that path.
> >>
> carefully at 
> > the multicast requirements and find ways to solve the easy and/or 
> > common cases first.  I do not think that there is a workable 
> > one-size-fits-all multicast solution.
> 
> misunderstanding the case I was describing. Based on the fact 
> that many application domains require point-to-point routing 
> and the expectation is many networks will be at most a few 
> hops across, there seems to be some consensus that keeping 
> multicast DAOs in is worthwhile. JP will have some results 
> indicating how much complexity they might add to an 
> implementation: his experience is not much.
> 
> So the current resolution is to keep multicast DAOs in, as 
> the belief is the use case described originally by Julien is 
> an important enough optimization to warrant their inclusion.
> 
> Phil
>