Subject: RE: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Mar 2001 00:12:37 +0200

Hi Samita

> > 	=> As I mentioned earlier, this would work at a cost of 
> > 	more complexity in the MN. 
> > 	Since, ROHC (or other HC techniques) are used 
> > 	in all "BW-challenged" links, I'm inclined to think
> > 	that this should be placed in a separate draft. 
> > 	As you know several people have mentioned that 
> > 	the draft is doing too much and we're working 
> > 	on that. 
> > 	I believe James' comments was related to context 
> > 	transfer which is handled by seamoby. After 
> > 	reading Mikael Degermark's (co-chair of ROHC) emails 
> > 	I'm now convinced that this would work fine. 
> > 
> > 	So to summarise, I think your proposal would 
> > 	work and I (and the rest of the co-authors)
> > 	would be more than happy to assist you in any 
> > 	way if you would like to write another draft that 
> > 	addresses this optimisation for HMIPv6. 
> > 
> > 	Finally, I would strongly recommend that you 
> > 	consult with the IPng folks as this solution
> > 	requires some special tricks in the implementation
> > 	and IPng is the best place to get feedback on 
> > 	this.
> > 
> I thought, at IETF we agreed on this solution :)
> I am not sure if this  option should go into a separate draft.
> But, we can discuss more. Regarding IPng folks, I think many IPng
> folks are also in this working group.
> 
	=> I'm not saynig it's not important or bad 
	(although it is messy to implement). All I'm saying
	is that since cellular networks and low BW 
	dial up lines already have HC, the benefits 
	are minor. The problem that James
	is referring to (compresor restart) will still occur 
	in this scenario since the header will change every
	time the MN moves. 
	So I'm still not saying it shouldn't be done and that's 
	clearly not for me to say, all I'm saying is that 
	it can be an option which would be good to document
	in another draft. We're already removing other 
	parts of the draft based on the WG comments.

	I don't tink that's a bad thing, we're trying to focus on the 
	major issues first.

> > 	We're not saying it's not important,but simply 
> > 	responding to the WG's comments about the 
> > 	size/scope of the draft
> 
> If you include the third option as an optional mode, that will give
> flexibility to the implementors to choose to implement this option.
> When 3GPP and 3GPP2 systems implement ROHC, I understand that then
> this option will be redundant. 
> 
	=> 3GPP has already approved it and I believe 3GPP2 is doing
	the same.

	Cheers,
	Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Mar 2001 11:02:19 -0800

Claude/Hesham,

  packets that arrive encapsulated from the HA, do they get decapsulated
before encapsulated by the MAP?

Theo

UCL / Mobile Systems

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Mar 2001 11:03:28 -0800 (PST)

I may be really off base here, but doesn't the 3G
MAC layer require fixed sized bandwidth increments
on the air? Eg, 8 kb/sec or something like that?
If so how well is ROHC really going to work?
Variable rate compression schemes don't usually
work very well with fixed bandwidth slot
architectures. I know that this is the reason, for
example, in DOCSIS (cable) they use a simpler (and
less bw efficient) form of payload header
suppression instead of CRTP/ROHC.

		    Mike