[rbridge] last call comment

[Radia Perlman]

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
>>   
>>     
>
>
>
>