Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-lmm-requirements-00.txt

From: [email-masked]
Date: Mon, 19 Nov 2001 08:28:37 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Localized Mobility Management Requirements for IPv6
	Author(s)	: C. Williams
	Filename	: draft-ietf-mobileip-lmm-requirements-00.txt
	Pages		: 14
	Date		: 16-Nov-01
	
This document describes requirements for Localized Mobility
Management (LMM) for Mobile IPv6.  These requirements are intended
to guide the design of a protocol specification for LMMv6.
Localized Mobility Management, in general introduces Local Mobility
Agent functionality for proxying a Regional care of address that
remains the same while the mobile node moves within a Local Mobility
Domain, which reduces the binding update signaling latency and the
signaling load outside the Local Mobility Domain. By its very nature
LMM also serves as a mechanism to hide the Mobile Node's location 
from observers outside the administration domain (Local Mobility 
Domain).  The identified requirements listed are essential for 
localized mobility management functionality. They are intended to 
be used as a guide for analysis on the observed benefits over the 
identified requirements for architecting and deploying LMM schemes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mobileip-lmm-requirements-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mobileip-lmm-requirements-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Cedric Westphal <[email-masked]>
Date: Mon, 19 Nov 2001 16:02:39 -0800

Hi,

there was an intense debate a couple weeks ago over the merits of
piggybacking. So we put together a little bit of analysis to bring the
discussion on less intuitive and more mathematical grounds.

The outcome of it is dual:
- The percentage improvement in bandwidth utilization is typically
   small.
- The percentage improvement in jitter during handover is typically
   large - actually, very large.

This basically says that piggybacking will not allow a provider to squeeze
more people on the same link, but that by not having piggybacking, the
user gets a significantly worst QoS.

The details will be available very soon at:
people.nokia.net/~rajeev/piggyback.ps

Cheers,

Cedric.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 11:01:45 +0100 (CET)

Your paper on p. 4 talks about "access delay" - is that thepropagation delay
over the  access link or the delay to get access to the link to send a packet?
I.e. it is the same as acquisition delay or something different?

Did you look at the difference  between BU specific piggybacking and
L2 piggybacking? (sending two IP packets in the same L2 frame)

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Nov 2001 09:22:34 -0800 (PST)

>    large - actually, very large.

   The problem here is that for things that are
   jitter sensitive, binding updates piggybacked
   or not are going to be inadequate in all but
   the most contrived laboratory settings. Speed
   of light, etc, mean that you need FMIP for fast
   convergence of the move, thus taking the long
   haul binding update out of the critical path.

 > user gets a significantly worst QoS.

   This presupposes that:

   1) jitter is important across the board
   2) that piggybacking is the only impediment 
      to getting jitter sensitive traffic
      delivered within the proper bounds.

   Neither of these are true.

	   Mike

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 20 Nov 2001 10:23:49 -0800

Erik,

it is the same as acquisition delay: propagation delay has to be added to this.
I did not look at the difference between BU specific piggybacking and L2
piggybacking: it seems to me that they are different issues. L2 piggybacking would

bring pretty much the same benefits, but if BU pb is supported by the user and
the server, then the QoS/perceived jitter is improved independently of the
underlying link technology with BU pb.
Take care,

Cedric.

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 20 Nov 2001 10:37:37 -0800

Mike,

please read the document before you comment the teaser.
Your mom  never told you not to judge a movie by its trailer?

Cedric.

>    haul binding update out of the critical path.

That's not the point of the debate we had. I thought you participated...

>    Neither of these are true.

1) Right, jitter is not important in a VoIP call. Have you heard of real time
applications? Duh.
2) Says who? YOU ONLY decided to add ONLY in presupposition 2). Of course,
pb is not the ONLY impediment. Piggybacking is not the solution to ALL problems.
Now, if you use piggybacking, you ALWAYS get an improvement for jitter sensitive
traffic. Because other factors in the network will add jitter as well, does this
mean that
you should not use piggybacking. It's like saying: don't wear a seatbelt, as it
is _not_ the _only_ implement
(oh my god, where did you fish 'impediment': piggyback does not obstruct timely
delivery
of jitter sensitive traffic, au contraire, mon frere) preventing death is car
crashes.

Neither of your point makes any sense.

Cedric.

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 20 Nov 2001 10:43:49 -0800

Just to point that even though I signed off early, there were comments inline.

Cedric.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Nov 2001 10:46:33 -0800 (PST)

> Your mom  never told you not to judge a movie by its trailer?

   I would appreciate if you'd keep this on a
   professional level. This post was nothing more
   than seething dismissal which does not lend to
   communication. If this is a win at all costs
   contest, there's really no point to this 
   discussion.

		Mike

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 20 Nov 2001 10:57:02 -0800

Mike,

I assume you did not read through the response. There
were technical and professional responses to your..what is
the professional word?... claims. However, for the sake of a
professional discussion,
I would appreciate if you would comment on the work of
others after reading it, and not just a few introductory sentences.

I don't know why you are talking about 'win at all costs': you are
making this into a battle, or into something personal. The all point
of the document is to bring some much needed objective analysis into
this.
There are no 'winners' and 'losers' in IETF, Mike, we are just trying
together to come up with the best protocols.

Hopefully, you can contribute in a positive way as well.
Thanks,

Cedric.