Subject: [Simple] Comments on interdomain scaling analysis

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Mar 2007 10:42:02 +0100

Hi,

Here are some comments on draft-ietf-simple-interdomain-scaling- 
analysis-00.txt.

One big concern is this draft claims to be standards track. That  
seems incorrect. The only milestone I see in the new charter that  
this could fall under is for an informational RFC.

I have a few nits on the model for the non optimized model, and a  
concern about the approach for the optimized models.

First the approach concern:

I'm starting to be uncomfortable with the idea of this draft talking  
about optimizations at all. We're doing sort of a backwards strawman  
here--putting up a potential optimization that has not been thought  
through by the work group as a whole, then assigning a value to it  
through optimization. This risks sending us down some false trails,  
or going down rat-holes arguing about the optimizations in the draft.  
it also risks getting us prematurely attached to a particular  
optimization, which could later turn out to be technically unfeasible.

Bottom line is, I think discussion of particular optimizations should  
be treated in a separate document than the analysis of the status quo.

Analysis model for non-optimized SIMPLE:

I think there are at least 2 errors and two areas that are likely to  
be misinterpreted.

Errors:

1) I think we have one too many rounds of subscription refreshes in  
the 8 hour period.  Looking at a timeline, there should be an initial  
subscription at t=0, one refresh at each of t=1 through t=7, and one  
tear-down at t=8. That's 1 initiation, 1 teardown, and _7_ refreshes,  
not 8.

2) The bandwidth calculation multiplies the number of messages times  
a size factor that includes an assumed request and response for each.  
But we already accounted for responses in the previous calculations  
on which this depends. Doing it here again causes a false doubling.  
(Not really quite double, since we assume a different size for  
responses than requests.)

Areas that should be clarified:

1) There are several lines labeled in the form of  <Method>/200 OK.  
That makes me think we are counting transactions. But in fact, we are  
counting messages. I think messages are the appropriate choice for  
this analysis, so it might make more sense to have a line item for  
each request type and a separate line for the associated responses. A  
misinterpretation here will make people think the numbers are twice  
as bad as they really are.

2) The population is listed as 20,000. But there is a buried  
assumption in the calculation that one domain has 20K people, and the  
peer domain also has 20K people, and the interdomain link is carrying  
traffic from all 40K people. People are likely to misinterpret this  
so that the numbers appear twice as bad as they really are. I suggest  
just acknowledging the population is 40K and removing the multiplier.

Keep in mind that if people fall into _both_ of this traps, they will  
misinterpret the numbers by a factor of 4.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Mar 2007 10:59:55 -0600

Ben Campbell wrote:

> through optimization. This risks sending us down some false trails, or 
> going down rat-holes arguing about the optimizations in the draft. it 
> also risks getting us prematurely attached to a particular optimization, 
> which could later turn out to be technically unfeasible.
> 
> Bottom line is, I think discussion of particular optimizations should be 
> treated in a separate document than the analysis of the status quo.

+1.

BTW I am working on a similar analysis for XMPP presence scaling. For 
purposes of comparison of presence technologies if for nothing else, I 
think it would be best for the analysis documents to analyze only, 
leaving discussion of improvements to other specifications.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml