Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof fs-v4-02.txt

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 19 Oct 2001 18:30:59 +1000

>  This assumes a few things:
> > 
> > - that the MIP signalling takes up significant
> > bandwidth
> >   and disrupts real time traffic
> > - that there is not enough extra bandwidth for the
> >   MIP signalling on that channel
> > - that there is no reserved signalling bandwidth or
> >   dedicated signalling channel.
> > 
> > Don't think these are assumptions we should rely on.
> 
> Please see my posting earlier this year, in which
> calculations for low bandwidth channels of the
> overhead introduced by MIP signalling run upwards
> of 100 ms or more. This would be enough to introduce a
> noticable disruption in voice traffic. The assumptions
> are based on calculated channel blocking times, and
> are not completely groundless. I can repost the
> numbers if you want, or you can check the archive for
> yourself.
> 
	=> Those calculations also assumed that the 
	voice traffic and the MIP signalling were sharing the 
	same channel, which goes back to the third assumption
	on Karim's list above. 

> > If we talk about real-time and channel access we
> > need to
> > consider QoS, radio realisations etc. but this is
> > complex and varies between wireless systems. I'd
> > prefer
> > if we kept low latency generic and left this work
> > for
> > the radio network implementors.
> > 
> 
> I don't think any of this is necessary. One simply has
> to look at how big the signaling messages are, how
> fast the channel is, and how long the L2 handover
> latency is. If the sum of the latency due to L3
> signaling and L2 handover exceeds user perception,
> then there will be a glitch. 
> 
	=> The point is, these calculations can not be 
	done in IETF for _all_ link layers and future ones.
	The draft offers different levels of support that are
	suited to different mobility scenarios. System 
	and radio interface designers can pick the appropriate 
	solutions accordingly. I believe the draft abstracts 
	the radio limitations to the extent that allows designers to 
	pick the right solution for their system.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Fri, 19 Oct 2001 09:43:25 -0700 (PDT)

Hesham,

> 	same channel, which goes back to the third

Not to belabor the point, but that is exactly what the
wording in my proposal was attempting to address.
If the voice traffic and MIP signaling are not
sharing the same channel, then there is no point in
implementing HTT. If you think the wording does not
capture that, then by all means please propose
something that is more precise.

> 	pick the right solution for their system.

Precisely. Which is why I believe that it is important
to specify that a radio protocol should implement HTT
if there is a problem with signaling obstructing real
time traffic.

It sounds as if we are in violent agreement. :-)

                    jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com