[rbridge] last call comment

[Dinesh G Dutt]

Why can't we limit the number of parents you pick to the number of trees 
that need to be computed ? The network topology that you state Jeff is 
not as common as you're suggesting, though it is a popular one,

Dinesh
jeff pickering wrote:
> Actually, by placing roots in differnt top tier groups, you guarantee 
> that there are no overlapping paths
> in any tree. So by definition, you load balance maximally.
>
> Radia Perlman wrote:
>   
>> It isn't me you have to convince. But a question...if there are that 
>> many paths, wouldn't people want
>> to load-split on most of them? If we limit it to 5, then the 5 parents 
>> with highest ID at the 2nd tier will
>> handle all the (multicast) traffic.
>>
>> I'd think that most of the traffic would be unicast, so it wouldn't 
>> really be a problem, but I suspect
>> there are other people who would not be happy with a limit like 5.
>>
>> Radia
>>
>>
>>
>>
>> Jeff Pickering wrote:
>>   
>>     
>>> Radia,
>>>
>>> Please understand that I am coming from the perspective of data center applications
>>> where the heavily predominant architecture is one of a 3 tier fat tree with a radix
>>> of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2
>>> for approximately 60% of the RBs (assuming top tier root placement which is what
>>> customers appear to want). I worry about the j mod p algorithm's impact on convergence 
>>> times in this scenario. 
>>>
>>> The algorithm provides no improvement in load sharing in this scenario either. And while
>>> I understand that writing a spec for a particular architecture is inappropriate (just look to
>>> What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p
>>> is really only ensured to help load sharing in the specific case of co-located roots or 
>>> at least located very close together. In other cases, it may actually decrease load sharing.
>>>
>>> I understand your point that b) is no change and that it decreases at least some aspects
>>> of the increased storage/sorting that needs to be done. However, I would still prefer c)
>>> (5 seems realistic) because it limits the impact of optimizing for co/near located root case
>>> while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b).
>>>
>>> I someone wants to load share more than a new architectural constant, they can always do this
>>> using root placement. Or if there is a real problem with the constant, we can always make it
>>> configurable and place each RBs value in an LSP (we already have similar mechanisms).
>>>
>>>
>>> Jeff
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
>>> Sent: Wednesday, July 01, 2009 6:02 PM
>>> To: Jeff Pickering
>>> Cc: rbridge at postel.org
>>> Subject: Re: [rbridge] last call comment
>>>
>>> Well, if we want to allow load splitting with at least p trees, then we 
>>> have to keep p parents.
>>>
>>> Alternatives to what is written, I think, are:
>>>
>>> a) keep as is: while computing the tree, keep all p parents.
>>>
>>> b) say that if p > j, then you only need to keep the top j choices of 
>>> parent. (this
>>> is true, and might be a good clarification to put in)
>>>
>>> c) say that load splitting choices will never be more than, say, 5 (an 
>>> architectural
>>> constant we will choose now and be stuck with forever), and then say 
>>> that the top
>>> "5" choices of parents must be kept (so that the actual choice, for tree 
>>> j, will
>>> be j mod 5).
>>>
>>> Choice b) does not affect the output-- it's just somewhat of an 
>>> optimization for how
>>> to compute the trees.
>>>
>>> Would saying that be sufficient, or would you prefer that we actually 
>>> limit the number of
>>> potential load splitting choices?
>>>
>>> Radia
>>>
>>>
>>>
>>> Jeff Pickering wrote:
>>>   
>>>     
>>>       
>>>>    
>>>>      Section 4.5.1
>>>>  
>>>>
>>>>    "When building the tree number j, remember all possible equal cost
>>>>
>>>>    parents for node N. After calculating the entire "tree" (actually,
>>>>
>>>>    directed graph), for each node N, if N has "p" parents, then order
>>>>
>>>>    the parents according to 7-byte ID. For tree j, choose N's parent as
>>>>
>>>>    choice j mod p."
>>>>
>>>>  
>>>>
>>>>    I really dont like the idea of keeping all P parents, esp in an 
>>>> environment
>>>>
>>>>    like fat tree where there may be dozens of upstream equal cost 
>>>> parents (times thousands of nodes).
>>>>
>>>>       That said, we should at least say whether "order the parents" 
>>>> means starting with lowest or highest.
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>      Section 4.5.2
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>       "In this case, R1-R2 adjacencies are ordered as follows, with
>>>>
>>>>       the one "most preferred" adjacency being the one that R1 transmits
>>>>
>>>>       to R2 on, and the one that R2 accepts traffic from R1 on:"
>>>>
>>>>  
>>>>
>>>>    
>>>>
>>>>       The way I read this, the statement is meaningless, R1 and R2 
>>>> both transmit to each other. So
>>>>
>>>>       either the intent is to say R1 (or R2) is the RB closer to the 
>>>> root. Or the intent is to say that depending
>>>>
>>>>       on whether traffic is flowing towards or away for the root, you 
>>>> may choose a different adjacency. Whichever
>>>>
>>>>       interpretation is intended should be clarified.
>>>>
>>>>  
>>>>
>>>>     Section 4.5.2
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>       Jeff
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>    
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>   
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>>   
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan