Subject: Re: [Isis-wg] draft-isis-pseudo-perlman-roy-thomas-00.txt

From: mike shand <[email-masked]>
Date: Mon, 03 Mar 2008 15:19:32 +0000

Dave Katz wrote:

I missed the beginning of this exchange, but I'm curious as to what
the *real* (as in "seconds" and "dollars" and "gigabytes" and
"megabits") costs are that are trying to be optimized.

Dave,

Well, for the case of 4 nodes per LAN and above it is clear that NOT
having a pseudonode requires both more memory and more computation than
having a pseudonode (see my previous posts on the trill list).

For 3 nodes on the LAN there is a small memory advantage for NOT having
a pseudonode (about 30 bytes per LAN). This would be about 30% IF there
were no "prefix" information in the database at all. But with any
appreciable amount of prefix information it pales into insignificance.

Computationally there is a tiny advantage for the non-pseudonode case,
but since an SPF even for a large (say 500 node) network only takes a
mS or so and it scales as n log(n), there doesn't seem a great deal of
point in trying to optimize that.

For n=2, having the pseudonode would cost about an extra 50 bytes per
LAN, which would be up to 50% with no prefix information, but again the
prefix information would probably swamp this.

Worst case the computation time would approximately double (if every
link in the entire network was a pt-pt link containing a pseudonode.

I really don't see it is worth the bother. All this is "under the
hood". The user doesn't see any significant difference in performance.

Last I heard, computational capacity and memory and bandwidth were
perilously close to being free, so the win has to be really big (in
real COGS in a real product, or a measurable percentage of bandwidth,
or a noticeable number of milliseconds in time) to make additional
complexity worthwhile, especially when traded off against the real
dollar costs of modifying and testing existing implementations.

Absolutely agree.

Mike

There was a proposal a few months back for a stripped down OSPF that
was supposed to be so much easier to implement, except that it was
incompatible with the existing protocol (which everyone has to
implement anyhow) and was probably an utterly pointless exercise even
if it *was* backward compatible due to the costs to the industry of
implementation. But it was more "efficient."

I'm also reminded of all of the effort put into various partial SPF
optimizations. They may make 100,000 node networks work better, but
SPF isn't the problem in a 100,000 node network.

And heck, a bunch of the complexity in OSPF itself is due to
optimizations for things that didn't matter a whole lot in 1989 and
sure don't matter now. I suppose it kept out the riffraff though.

I have a rule of thumb in coding that says that if the gain isn't
better than linear, it doesn't really help scaling.

Anyhow, "50%" sounds like a big number, but what does this mean in
bytes and milliseconds for typical deployments?

--Dave

On Feb 29, 2008, at 1:51 PM, James Carlson wrote:

Radia Perlman writes:

If it's mostly pt-to-pt links, then 50% more nodes does not seem like
trivial overhead. It's not just bytes. It's also
computation time.

I think this case is interesting because it very likely occurs with a
fully-deployed TRILL network. In the case of TRILL, because each node
is behaving as a layer 2 bridge, and because 10BASE-[25] are pretty
dead, the links will almost certainly all be connected point-to-point
but (again because this is bridging) using 802 broadcast-type media.

And because this is bridging, and TRILL is meant to replace existing
bridges which generally default to useful settings, zero-configuration
is very highly desirable. Thus we can't rule out accomodating
occasional (but rare) links that are connected to repeaters or
old-style bridges and thus have three or more nodes on them.

The result is that you very likely get into a case where you've got
almost all point-to-point connections among a large number of nodes
using broadcast-type interfaces. Each of those (without special
configuration) requires an extra pseudonode, which is (as Radia's
pointing out) a waste of everyone's time, bandwidth, cycles, and
memory.

Perhaps the real argument here is that because the motivation behind
this is tied to artifacts of TRILL deployment, it ought not be made
generic, and instead be made part of the special IS-IS variant used
for TRILL (and any other case where all your Ethernet ports end up
being just point-to-point).

--
James Carlson, Solaris Networking <[email-masked]

Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442
2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
1677
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Dave Katz <[email-masked]>
Date: Mon, 3 Mar 2008 09:46:57 -0800

On Mar 3, 2008, at 7:19 AM, mike shand wrote:

> having a pseudonode requires both more memory and more computation  
> than having a pseudonode (see my previous posts on the trill list).
>
> For 3 nodes on the LAN there is a small memory advantage for NOT  
> having a pseudonode (about 30 bytes per LAN). This would be about  
> 30% IF there were no "prefix" information in the database at all.  
> But with any appreciable amount of prefix information it pales into  
> insignificance.
>
> Computationally there is a tiny advantage for the non-pseudonode  
> case, but since an SPF even for a large (say 500 node) network only  
> takes a mS or so and it scales as n log(n), there doesn't seem a  
> great deal of point in trying to optimize that.
>
> For n=2, having the pseudonode would cost about an extra 50 bytes  
> per LAN, which would be up to 50% with no prefix information, but  
> again the prefix information would probably swamp this.
>

Thanks.  Just old and cranky, as usual.

--Dave

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Mon, 3 Mar 2008 23:26:09 -0000

This is about ease of configuration.
 
This is NOT about appreciable speed increase for the customer. we are in the noise as we have been saying for 6 months now. We have ruled out that there is any DECREASE in performance. In fact there is a slight INCREASE in performance if under 4 which is very likely in most networks with VLANs / pt-2pt. This is a super bonus but not the point at all. 
 
My 2 cents :o)
 
Matthew Thomas

________________________________

From: [email-masked] on behalf of mike shand
Sent: Mon 03/03/2008 15:19
To: Dave Katz
Cc: Radia Perlman; [email-masked]; James Carlson
Subject: Re: [Isis-wg] draft-isis-pseudo-perlman-roy-thomas-00.txt

Dave Katz wrote: 

Dave,

Well, for the case of 4 nodes per LAN and above it is clear that NOT having a pseudonode requires both more memory and more computation than having a pseudonode (see my previous posts on the trill list).

For 3 nodes on the LAN there is a small memory advantage for NOT having a pseudonode (about 30 bytes per LAN). This would be about 30% IF there were no "prefix" information in the database at all. But with any appreciable amount of prefix information it pales into insignificance.

Computationally there is a tiny advantage for the non-pseudonode case, but since an SPF even for a large (say 500 node) network only takes a mS or so and it scales as n log(n), there doesn't seem a great deal of point in trying to optimize that.

For n=2, having the pseudonode would cost about an extra 50 bytes per LAN, which would be up to 50% with no prefix information, but again the prefix information would probably swamp this.

Worst case the computation time would approximately double (if every link in the entire network was a pt-pt link containing a pseudonode.

I really don't see it is worth the bother. All this is "under the hood". The user doesn't see any significant difference in performance. 

Absolutely agree.
    Mike

	

	
	--Dave

		Radia Perlman writes:

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 3 Mar 2008 16:06:21 -0800

Matthew -

OK - you seem to be stating that the motivation for this extension is
NOT performance related.

As for zero configuration - we have a very nice existing solution for
that:

a)Treat LAN subnets as LANS regardless of how many neighbors exist
b)Treat Pt-Pt subnets as Pt-Pt

So what problem is left that requires the introduction of this protocol
extension?

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Thomas, Matthew R
> Sent: Monday, March 03, 2008 3:26 PM
> To: [email-masked]
> Cc: Mike Shand (mshand)
> Subject: [Isis-wg] FW: draft-isis-pseudo-perlman-roy-thomas-00.txt
> 
> This is NOT about appreciable speed increase for the customer. we are
in
> the noise as we have been saying for 6 months now. We have ruled out
that
> there is any DECREASE in performance. In fact there is a slight
INCREASE
> in performance if under 4 which is very likely in most networks with
VLANs
> / pt-2pt. This is a super bonus but not the point at all.
> 
> My 2 cents :o)
> 
> Matthew Thomas
> 
> 
than
> For 3 nodes on the LAN there is a small memory advantage for NOT
having a
> pseudonode (about 30 bytes per LAN). This would be about 30% IF there
were
> no "prefix" information in the database at all. But with any
appreciable
> amount of prefix information it pales into insignificance.
> 
but
> since an SPF even for a large (say 500 node) network only takes a mS
or so
> and it scales as n log(n), there doesn't seem a great deal of point in
> trying to optimize that.
> 
LAN,
> which would be up to 50% with no prefix information, but again the
prefix
> information would probably swamp this.
> 
link
> in the entire network was a pt-pt link containing a pseudonode.
> 
hood".
> The user doesn't see any significant difference in performance.
> 
> 
> 
> 
> 
> 
> 			If it's mostly pt-to-pt links, then 50% more
nodes does
> not seem like
> 		I think this case is interesting because it very likely
occurs
> with a
> 		fully-deployed TRILL network.  In the case of TRILL,
because
> each node
> 		is behaving as a layer 2 bridge, and because 10BASE-[25]
are
> pretty
> 		dead, the links will almost certainly all be connected
point-
> to-point
> 		but (again because this is bridging) using 802
broadcast-type
> media.
> 
> 		And because this is bridging, and TRILL is meant to
replace
> existing
> 		bridges which generally default to useful settings,
zero-
> configuration
> 		almost all point-to-point connections among a large
number of
> nodes
> 		configuration) requires an extra pseudonode, which is
(as
> Radia's
> 		pointing out) a waste of everyone's time, bandwidth,
cycles,
> and
> 		memory.
> 
> 		Perhaps the real argument here is that because the
motivation
> behind
> 		this is tied to artifacts of TRILL deployment, it ought
not be
> made
> 		generic, and instead be made part of the special IS-IS
variant
> used
> 		for TRILL (and any other case where all your Ethernet
ports
> end up
> 		Sun Microsystems / 35 Network Drive        71.232W   Vox
+1
> 781 442
> 		2084
> 		MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax
+1
> 781 442