Subject: RE: [mobile-ip] Some Analysis

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 28 Apr 2001 02:40:13 +0200

Phil N, 

> Please quantify your response.  You are complaining about the lack
> of numbers yet provide none. 
> 
	=> Well maybe there are too many mails to read on 
	this list, but I have already done that. 
	The typical figures that I know of (you can easily 
	check that) for forwarding delays in some 
	major routers are roughly 1-2 ms (I'm being concservative,
	some routers can do much better). 
	Delays over the air in CDMA (eg. WCDMA )
	are 60 - 80 ms (80 being the worste case scenario) 

>  At least we have a delay model with
> what James has provided.
> 
	=> I know, I did also agree with that.

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 28 Apr 2001 23:06:05 +0200

Hi Jim, 

> But your or Erik have not proven there is no significant benefit either.
> I feel your response is using a logic model that states one cannot deduce
> anything from mathematical properties and James also did the inequalities
> too. So I would argue his logic table was duplicate with an addition
> discrete logical component.
> 
	=> Let me just state that the model Jim sent was fine.
	I tried to put it in the right context. Does it really 
	matter if we save 3 or 4 ms if we have a 70 ms delay ?
	Or put differently, is there a siginificant gain is reducing 
	the delay from 76 to 73 ms ? 
	I can't see a significant difference but I might be missing 
	something. 

> And as another comment do you know how many I told you so cards I am
> holding where Ipv6 made choices to defer a minimum performance gain with
> the argument that "no significant gain is made".  A lot.  Know what.  I
> built an IPv6 stack.  And we had to make up for all those decisions as
> implementors in our production IPv4/v6 stack.
> 
> So at this point with your comment I will say now I am digging my heels in
> to the chairs and saying arguments of this sort are simply not fair in
> this case.  The distribtution of hierarchy in this case will also cause
> ease of management at each level and with LDAP, Agentx, or a host of other
> user level protocols can be managed quite easily and maintained at the top
> of the hiearchy.
> 
	=> I can appreciate your logic, but I think that the 
	"no signifigant gain" argument should be backed up
	by propoer reasoning. If not then what you mention
	above may happen. Of course I'm saying this 
	in general without knowing what specific case 
	you're referring to. But in this particular example
	I've attempted to show numbers that some of us 
	(including James I'm sure) are aware of to see 
	whether the gain is significant enough to introduce 
	a clearly less robust and more complex/expensive
	solution.

> Not picking on you or Erik but the argument OK.  
> 
	=> Sure.

> Also I see a mege of RegRe and HMIPv6 with minimum alteration to either.
> But give and take would be required.
> 
	=> As discussed before and suggested by Raj, there is 
	nothing wrong with using ideas from other drafts of course. 
	The point of the exercise is to highlight the requirements.
	When we argee on them we can then see what's missing 
	from the current proposal. If requirement X is not met 
	_and_ the best solution for it is in draft A, then why not. 

	So IMHO saying that a merger is needed is a bit premature, 
	first we should agree (by consensus of course) on the 
	requirements, then see what requirements are not 
	met and finally identify the best way of solving it. 

	As Karim said earlier, multi-level hierarchy is already
	supported in the current proposal (for the MR case). 
	Of course it can be further optimised if that's what 
	the WG wants. But it is very important to make sure
	that whatever functionality we add is actually needed.
	IMO too many options can kill any proposal. 

	Thanks,
	Hesham