Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...)

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 16 Mar 2001 01:04:54 +0100

> I don't want to get into a long discussion over this, since I've
> got a lot of other stuff to do before I leave for the Mini-Apple
> on Sun., but the fact remains that both hierarchical proposals introduce
> extra signalling and also some extra tunneling overhead over the air.
> Air resources are scarce if the network operator needs to pay for them,
> and so reducing air time is a significant plus.
> 
	=> Sure air resources are scarce and expensive, especially 
	in many cellular systems where they cost billions. 
	BUT, even one IPv6 header is too expensive, especially for real
	time services. So what does every IP based cellular system
	do, they use Header compression. It can handle tunnelling. 

	There are several other protocols in MIP and outside that 
	require tunnelling to the host, so why is this a special case ?

> I think that Glenn's proposal deserves a serious look. 
> 
	=> Of course. every proposal does, but we need to see 
	a justification/requirements for proposals.

> If it
> turns out not to work, then we can return to one of the existing
> proposals. And there may be other reasons (like providing a local home address 
> for homeless clients, as the MAP can) to use one of the existing
> solutions.
> 
	=> Agreed.

> I suppose a good set of requirements would have helped to avoid these
> problems.
> 
	=> Agreed. We've included our requirements in the draft 
	and in all our IETF presentations and I encourage 
	others to do the same. 
	What I do discourage (and it's clearly not my decision)
	is not highlighting what's missing in an existing WG
	draft. All I want to see is a valid requirement that we have 
	missed or a fundamental problem with the proposal. 
	We normally respond by adding the missing bits 
	as we've shown in previous revisions.

	Is this so hard to get ? I hope not.Otherwise the 
	discussions are subjective and not very fruitful.

	Regards,
	Hesham

> >X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to 
> [email-masked] using -f
> >From: "Hesham Soliman  (ERA)" <[email-masked]>
> >To: "[email-masked]'" <[email-masked]>
> >Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt
> >Date: Thu, 15 Mar 2001 20:48:40 +0100
> >MIME-Version: 1.0
> >List-Archive: <http://playground.sun.com/mobile-ip/>
> >List-Owner: <mailto:[email-masked]>
> >List-Subscribe: <mailto:[email-masked]?body=subscribe>
> >List-Unsubscribe: 
> <mailto:[email-masked]?body=unsubscribe> Sorry to jump in 
> as you were addressing Glenn,  but I have to correct some misunderstandings 
> about HMIPv6.
> >
> >> > Hello,
> >> > 
> >> > I still do not understand why the ability to place something at an 
> arbitrary point justifies destroying the connectionless nature of a IP or even 
> IP mobility.
> >> 
> >> Once we introduce an intermediary point (HA/RMA/MAP) with mobility bindings
> >> we introduce state used in a similar way as state used for maintaining
> >> plain next hop forwarding. 
> >> 
> >	=> The  next hop forwarding in the MAP depends on the routing 
> >	protocols in the domain. The next hop forwarding in Regional
> >	is forced (like a static route). There is a big difference. 
> >	You might ague that reg6 is part of MIP, hence can be 
> >	classified as a routing protocol, but I would say that 
> >	any routing protocol that reserves a "circuit-like" path
> >	in the IP network is not acceptable.
> >
> >> I read your use of term connection-oriented to
> >> mean the use of mobility bindings for forwarding instead of exclusively 
> relying on host/network/default routes. Introducing robustness
> >> in this form of forwarding is a problem both HMIP and regreg6 face.
> >> In fact, even basic Mobile IPv6 while forwarding packets via the
> >> home agent has this feature.
> >> 
> >	=> The robustness in terms of introducing a single point 
> >	of failure may be similar, but adding a less robust path
> >	to the MN from the GMA is not acceptable, and clearly 
> >	this is not just my opinion.
> >
> >	Regards,
> >	Hesham

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 15 Mar 2001 19:14:44 -0800

>         do, they use Header compression. It can handle tunnelling.

There are some reasons why we can do better by considering last hop
resource usage on the network layer than delegating it to the header
compression, which is a link-layer optimization. To my knowledge,
header compression is application specific. You need to set up the
context to use it and that depends on what application you are
running. Setting it up for voice is different from e.g. for video.
What if you have application for which you do not have a method?

If you can strip tunneling by a simple application-independent
IP forwarding trick, then why not? Also, why should we mandate
support for header compression to have efficient bandwidth usage?
I do not think we should ignore WLAN-like interfaces, either, where
header-compression is not included.

This is because if we care about scalability we have also the
dimension of multiple mobile nodes. Even though your bandwidth may
be 11Mbps, that does not mean it cannot be crowded by simply having
a big enough number of mobile nodes. I believe we provide an
alternative design where these issues are considered at least to
some degree, and as options not mandated by the base design.

Best Regards,

-Jari