Subject: [Mip4] Re: This message announces a WG last call on: draft-ietf-mip4-fmipv4-01.txt

From: Ajoy Singh <[email-masked]>
Date: Mon, 18 Sep 2006 04:12:07 +0100 (BST)

Hi, Pete, 

Is the intent of this last call is allow publication of 

FMIPv4 as proposed standard or experimental RFC? 

MIPv4 charter seems to indicate that the goal of the WG is to publish FMIPv4 as an experimental 

RFC whereas the email is indicating otherwise? Can you please clarify? 

Regards,

Ajoy 

This message announces a WG last call on:
   
   "Mobile IPv4 Fast Handovers"   - draft-ietf-mip4-fmipv4-01.txt
  
The last call will conclude at 24:00 UTC on Tuesday, 19 September 2006.

"Mobile IPv4 Fast Handovers" describes new messages and procedures  for allowing a mobile node to regain connectivity at a new point  of attachment prior to completing an end-to-end MIPv4 registration.
  
A URL for this Internet-Draft is:
  
<http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-01.txt>

Please respond to this WG last call:
  
* If you have no comments on the draft, and support its advancement,    simply respond with a line containing something like
  
   "I support the advancement of this document to the IESG with a      request for publication as proposed standard."
  
  If you have comments, please use a line similar to the one above, and    supplement this with your comments.

* If you *don't* support its advancement, respond with a line containing    something like the following, supplemented by your comments -
    "I don't support the advancement of this document to the IESG with      a request for publication as proposed standard, for the following      reasons:"     ...
  
 Pete & Henrik

--  Mip4 mailing list: Mip4 at ietf.org     

---------------------------------
      
   Prev by Date: Re: [Mip4] Mobile IP implementation   
   Next by Date: [Mip4] MIP4 client implementation (http://www.mip4.org/2006/implementations/ )   
   Previous by thread: [Mip4] CFP Tridentcom 2007 - Extended Paper Submission Deadline - September 15, 2006   
   Next by thread: [Mip4] MIP4 client implementation (http://www.mip4.org/2006/implementations/ )   
   Index(es):     
      Date   
      Thread 

  Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF. 
 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Pete McCann <[email-masked]>
Date: Mon, 18 Sep 2006 09:22:39 -0500

Hi, Ajoy,

My apologies, the last call text was borrowed from an earlier
e-mail.  The intent is to publish FMIPv4 as Experimental RFC,
as indicated on the MIP4 charter.

-Pete

Ajoy Singh wrote:
> "Mobile IPv4 Fast Handovers" describes new messages
>  and procedures  for allowing a mobile node to regain connectivity at a new point  of attachment prior to completing an end-to-end MIPv4 registration.
> 
> 
> * If you have no comments on the draft, and support its advancement,    
> simply respond with a line containing something like
> 
>    "I support the advancement of this document to the IESG with a      
> request for publication as proposed standard."
> 
>   "I don't support the advancement of this document to the IESG 
> with      a request for publication as proposed standard, for the 
> following      reasons:"     ...
> 
>  Pete & Henrik
> 
>  
> 
> ------------------------------------------------------------------------
> 
>     * Prev by Date: *Re: [Mip4] Mobile IP implementation
>       <http://www1.ietf.org/mail-archive/web/mip4/current/msg02053.html>*
>     * Next by Date: *[Mip4] MIP4 client implementation
>       (http://www.mip4.org/2006/implementations/ )
>       <http://www1.ietf.org/mail-archive/web/mip4/current/msg02055.html>*
>     * Previous by thread: *[Mip4] CFP Tridentcom 2007 - Extended Paper
>       Submission Deadline - September 15, 2006
>       <http://www1.ietf.org/mail-archive/web/mip4/current/msg02051.html>*
>     * Next by thread: *[Mip4] MIP4 client implementation
>       (http://www.mip4.org/2006/implementations/ )
>       <http://www1.ietf.org/mail-archive/web/mip4/current/msg02055.html>*
>     * Index(es):
>           o *Date*
>             <http://www1.ietf.org/mail-archive/web/mip4/current/maillist.html#02054>
> 
>           o *Thread*
>             <http://www1.ietf.org/mail-archive/web/mip4/current/threads.html#02054>
> 
> 
> 
>         Note: Messages sent to this list are the opinions of the senders
>         and do not imply endorsement by the IETF.
> 
> ------------------------------------------------------------------------
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
> <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com> 
> 
>

---

From: Ajoy Singh <[email-masked]>
Date: Tue, 19 Sep 2006 01:37:52 +0100 (BST)

Thanks for clarification. 
   
  Regards,
  Ajoy 
  
Pete McCann <[email-masked]> wrote:
  Hi, Ajoy,

-Pete

Ajoy Singh wrote:
> Hi, Pete, 
> 
> 
> 
> Is the intent of this last call is to allow publication of 
> 
> *
> *
> *
> *

---

From: Pete McCann <[email-masked]>
Date: Tue, 19 Sep 2006 09:47:09 -0500

By the way, this last call ends TONIGHT at midnight.  So far we have
not received any comments.  The draft cannot be moved forward unless
we get substantive support on the mailing list.

-Pete

Ajoy Singh wrote:
> */Pete McCann <[email-masked]>/* wrote:
> 
>     Hi, Ajoy,
> 
>      > and procedures for allowing a mobile node to regain connectivity
>     at a new point of attachment prior to completing an end-to-end MIPv4
>     registration.
>      >
>      >
>      > * If you *don't* support its advancement, respond with a line
>     containing something like the following, supplemented by your comments -
>      >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Sep 2006 17:54:22 +0200

> we get substantive support on the mailing list.

It would be advantageous to the document to mention typical experimental
link-layer handover delays for 802.11b and typical DHCP address
acquisition delays, maybe somewhere in the introduction.

Depending on MN hardware and on the way the 802.11 handover is performed
(scan-attach, attach-to-preset-AP, attach-attach) these range between
20ms to 5s, and from 2s to 8s respectively (no FMIPv4 used).

If more interest in numbers shows up, it may be even more advantageous
to mention what FMIPv4 promisses in terms of handover delay improvement
(the _fast_ word), or in terms of reducing packet loss.  Or maybe what
it promisses in terms of improving the user experience of the IP
application.

Alex

>> Regards, Ajoy
>> e-mail. The intent is to publish FMIPv4 as Experimental RFC, as 
>> indicated on the MIP4 charter.
>> 
>> -Pete
>> 
>> 
>> Ajoy Singh wrote:
>>> Hi, Pete,
>>> 
>>> 
>>> 
>>> The last call will conclude at 24:00 UTC on Tuesday, 19 September
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 2006.
>>> 
>>> 
>>> "Mobile IPv4 Fast Handovers" describes new messages and 
>>> procedures for allowing a mobile node to regain connectivity
>> at a new point of attachment prior to completing an end-to-end 
>> MIPv4 registration.
>>> 
>>>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 19 Sep 2006 09:07:53 -0700

Hmmm, what would be the point of mentioning specific numbers? Any
numbers will in fact be either too broad to be useful, like the 20ms-5s
range you provided, or too narrow to be correct.

My point is that delays depend on a lot of things that have nothing to
do with the protocols involved but have to do with transmission delays,
loading, implementation efficiency, network configuration, number of
links/switches/routers involved. I would not know were to begin to
define what is "typical" in any of this.

At best, one can provide experimental data based on a very specific
set-up.

George

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2006 11:54 AM
> To: Pete McCann
> Cc: [email-masked]
> Subject: Re: [Mip4] Re: This message announces a WG lastcall on:
draft-
> ietf-mip4-fmipv4-01.txt

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 19 Sep 2006 09:09:31 -0700

BTW, I do think it is OK to publish this draft as experimental, only to
document this option, although is has not yet found many takers in the
market.

George

> From: Pete McCann [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2006 10:47 AM
> To: [email-masked]
> Subject: Re: [Mip4] Re: This message announces a WG last callon:
draft-
> >     at a new point of attachment prior to completing an end-to-end
MIPv4
> >      > If you have comments, please use a line similar to the one
above,
> >      > and supplement this with your comments.
> >      >
> >      >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Sep 2006 19:22:46 +0200

Tsirtsis, George wrote:
> numbers will in fact be either too broad to be useful, like the 
> 20ms-5s range you provided, or too narrow to be correct.

That was but an example, purposefully ranged wide to stay correct with a
few words.  And I don't see what you see wrong in mentioning in the
draft that 802.11b handovers happen in that range of delays.

It is very useful to know a 802.11b handover can last 20ms.  It gives a
lower boundary.  802.11g has lower boundaries.

It is very good to know it can last 5s.  It gives an upper boundary.
DHCP has a longer upper boundary.

It is very good to have narrower results, with more reporting on the
experimentation conditions.  It approaches "correctness" to the best of
someone could do.  True correctness doesn't exist, like one can't say
where a particle is, but one could do a lot of helpful things in
approaching that uncertainty.

> My point is that delays depend on a lot of things that have nothing 
> to do with the protocols involved but have to do with transmission 
> delays, loading, implementation efficiency, network configuration, 
> number of links/switches/routers involved.

There is indeed a huge amount of things happening during 1second in all
these computers.  But, giving up understanding them makes us talk about
"fast" when we don't know what is "slow".  This is not engineering.

> I would not know were to begin to define what is "typical" in any of 
> this.
> 

Yes.  That would be more helpful than a blank space.

It could sound like this: it has been noticed that the vaganza PCMCIA
card on a 1Ghz T83 laptop changing attachment between two airospeak
802.11b APs, by manually changing the MAC address of the AP, and without
security, it takes around 30ms, in a Feredei cage.  This is just an
example, and other environments exhibit other properties.

Agree, this figure is probably not typical.  But it may be a debut, and
one could poll the members in this group to find out a "typical" answer.

Even a measurement performed years ago qualifies, it will be tagged as
such.

Alex
PS: would you otherwise prefer to mention in the draft that "there is no
     point to mention specific numbers, here's why."

---

From: Ajoy Singh <[email-masked]>
Date: Wed, 20 Sep 2006 02:26:03 +0100 (BST)

Given that similar protocol (LLH) has been already approved for publication, I do not see any good reason to publish yet another protocol.  
   
  Regards,
  Ajoy 

-Pete

Ajoy Singh wrote:
> */Pete McCann /* wrote: