Subject: [mobile-ip] WG Feedback Requested

From: Phil Roberts <[email-masked]>
Date: Tue, 18 Dec 2001 18:46:43 -0500

I'd like to get working group feedback on the low latency draft and
part of the route optimization draft.

First, how urgent is the need for the low latency draft to become an RFC?
I was rather disappointed to see that only a few people are planning on
implementing any part of this.  Given that, it's hard for me to see whether
there is any urgency at all.

Second, it was proposed that PFANE from the RO draft might be stripped
into a separate draft to accelerate progress on low latency.  The background
issue here is that the chairs (well, me) have sat on the route optimization
draft pending some resolution of the route optimization issues for MIPv6.
I'd like to have some feedback about the RO draft, so could you please
comment
on whether you are actually going to use any part of route optimization
(other
than PFANE), and whether you'd like to push me to go ahead and send route
optimization for v4 to the IESG before the MIPv6 issues are resolved.  Route
optimization completed WG last call sometime before March of this year.

Phil

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Wed, 19 Dec 2001 10:00:13 -0600

One possbility is to consider making the low-latency draft an
experimental RFC. That will give implementers an opportunity to
work with a spec that is "relatively" stable while discovering issues.
We could take it to proposed standard once we have a better 
understanding of the low-latency implementations for MIPv4.

-Basavaraj

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 19 Dec 2001 19:22:20 +0100

Going back to where we were several IETFs ago just sounds to me like
delaying the work. I thought basic functionality was already clear in
the doc through the MAY/SHOULD/MUSTs, but if not let's clarify it now.

 > 
 > GT> Karim, it is well understood that for Make Before Break 
 > handoffs such as
 > all the inter-technology handoffs and any good enough link 
 > layers that also
 > allow it there is no need for the fast handoff specs. These 
 > are specifically
 > needed for break before make handoffs. But lets not get 
 > hanged up on this
 > the point is that you also agree that the PFANE proposal could be
 > standardized independently.
 
We agree this is outside the scope of low latency. Appendix B spells
out that there MAY be different ways of doing fast handoffs in certain
cases.

/Karim

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 19 Dec 2001 19:26:30 +0100

=> Amen ! Especially if all you have is an ethernet
link. You can't claim to have implemented something
like BETH, POSTREG ...etc on an ethernet, unless you're
triggering it manually !

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 19 Dec 2001 20:07:10 +0100

Vijay, 

I know, I was confirming what you said actually, 
I should say 'one can't claim to have implemented ...'
sorry for the confusion.

Hesham

  > -----Original Message-----
  > From: Vijay Devarapalli [mailto:[email-masked]]
  > Sent: Wednesday, December 19, 2001 8:03 PM
  > To: [email-masked]
  > Subject: Re: [mobile-ip] WG Feedback Requested
  > 
  > 
  > Hesham,
  > 
  > Is this for me? I havent implemented BETH or POSTREQ.
  > And I never claimed I did. on the contrary, I was saying
  > that we cant implement anything which depends on L2 
  > triggers.
  > 
  > Vijay
  > 
  > 
  > "Hesham Soliman (ERA)" wrote:
  > > 
  > > That was a reply to Vijay actually, don't know why
  > > half my email disappeared !
  > > 
  > >   > -----Original Message-----
  > >   > From: Hesham Soliman (ERA) 
[mailto:[email-masked]]
>   > Sent: Wednesday, December 19, 2001 7:27 PM
>   > To: [email-masked]'
>   > Subject: RE: [mobile-ip] WG Feedback Requested
>   >
>   >

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 20 Dec 2001 05:48:11 -0500

Yes, I do not know where the idea of PFANE *replacing* fast handoffs came
from. What I said is that make before break handoffs do not need fast
handoffs, which I hope is well understood since it was clearly stated when
we started working on fast handoffs...Yet for break before make these are
essential for good performance.

PFANE can help with packet loss not with letancy.

George

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Thursday, December 20, 2001 4:40 AM
To: [email-masked]
Subject: Re: [mobile-ip] WG Feedback Requested

Few general comments....

The discussions on FMIPv4 surely
maps to FMIPv6... (an obvious
observation)

I think while PFANE is an improvement
over regular MIPv4 as far as low
latency is concerned, I don't think
it can be as fast as prereg. Exchanging
protocol signaling after the L2 handover would 
be slower.

I think both approaches have L2 trigger
requirements. How can one not require any?
So saying postreg requires triggers is
misleading. prereg does too.
It's just they have different L2 trigger
requirements.

Because what postreg requires (source/target triggers)
is not available on every link, we need prereg. And that's 
where people can use prereg. I think this is obvious 
even without comparing numbers.

alper

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 19, 2001 11:52 AM
Subject: Re: [mobile-ip] WG Feedback Requested

> Hesham,
> 
> ----- 
> Hesham,
> 
> > => Aha ! Thanks for the enlightenment, but you've missed
> > my point. Your theoritical analysis was 
> > based on an implementation on a cellular link
> > with certain characteristics (e.g. you had to 
> > send MIP signalling on the same channel as the
> > traffic data). Now your implementation is 
> > on an ethernet, so I'm not sure which theory 
> > that confirms.
> 
> Look at the simulation description
> in http://geocities.com/kempf42/llanalysis.pdf. 
> The simulation was designed to work like a cellular link
> (10 ms latency on the simulated radio channel).
> 
> > In addition, the standard we follow is RFC2002, 
> > your implementation didn't follow that standard, 
> > so what do you disagree with when I say that 
> > the implementation is not correct ?
> > Please clarify this to me.
> > 
> 
> Again, you are misrepresenting the discussion that
> Jon and Karim had on the mailing list. Our
> code was based on Solaris MIPv4, which 
> implements RFC2002. How can you say
> that our implementation doesn't follow
> the standard when you've never looked at it?
> 
> > 
> >   > 
> >   > If you want to prove these wrong, then I suggest
> >   > you implement Prereg and show results that
> >   > contradict the ones I presented. We are not talking about
> >   > extraterristrial abductions here.
> > 
> > => I don't have to implement it to show you 
> > you've done something wrong, I can read 
> > text ! section 4.1.1 of your paper is only one 
> > example of the wrong implementation  and there 
> > is more.
> >  
> 
> No, but you have to implement something
> to prove to the working group
> that you've done something worth having
> lots of people implement as a standard. IETF
> is not an academic conference where people
> publish theoretical papers then everybody
> forgets about them. The work we do is
> implemented and deployed by many companies
> at great expense. It is incumbent upon us 
> to prove that what we promote as a standard
> works as claimed.
> 
> Now, Jon and I have done some implementation
> work that shows Prereg doesn't work very
> well for particular kinds of radio links. You
> and Karim are the authors of Prereg. If you
> think we are wrong, implement it yourselves
> and prove us wrong!
> 
> > => Separating the draft again is simply 
> > irrational and takes us back a year. 
> > If the WG decides on the next steps, we
> > should abide of course, but I want to make
> > it clear that we have the right foundations
> > for othe decision. And that definitely (no offence) 
> > should not be based on the presentation in SLC, 
> > because anyone who reads the paper will realise
> > where the errors are. 
> > 
> 
> Hesham, I've argued from the start that the
> WG should select either one or another of
> the techniques. The so-called "errors" in
> the SLC presentation are your misrepresentations
> of conversations between Jon and Karim on
> the mailing list. You have not ever addressed
> my specific question of Prereg's failure
> when the MN is moving too fast to
> complete the Prereg signaling on the
> old FA.
> 
> Until you address this, your arguments are
> completely baseless. 
> 
> 
>             jak
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 20 Dec 2001 12:14:52 +0100

=> Like a radio channel ???! You're assuming latency
is the only charactersitic of a radio channel. 
So can you please tell us, did you simulate it 
or implement it ? Because previously you claimed to
have implemented it. It's NOT the same thing btw.

  > the standard when you've never looked at it?
=> Have you been reading the emails ?? Jon explained
how his implementation works and it was clearly wrong.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 20 Dec 2001 18:27:16 +0100

I will obviously ignore replying to this 
stupidity on a public list. You've just shown
your own implementation and conversational skills

  > From: James Kempf [mailto:[email-masked]]
  > Sent: Thursday, December 20, 2001 11:49 AM
  > >   > The simulation results we did showed that a technique
  > >   > similar to PFANE worked about as well as Prereg.
  > >   > The paper is at
  > >   > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-ha
  > > ndover-00.tx
  > > 
  > > => Did you simulate it or implement it ?????????
  > > 
  > > 
  > > t
  > > Of course, we will have to do simulations for
  > > PFANE itself to be sure.
  > > 
  > > => So how can you make the claims above if you 
  > > didn't simulate both on the exact same environment ??????
  > > Please be consistent with your claims.
  > > 
  > 
  > Read the paper. It contains a description of the
  > experimental method, and if it isn't clear,
  > then I'll be happy to clarify.
  > If you have any implementation skills at
  > all, it should be enough to allow you to duplicate
  > the work and either verify or refute our results.
  > That's what engineering and science are all
  > about, not sniping on mailing lists at people who do real
  > work in an attempt to find out whether something
  > works or not.
  > 
  > And, that's about all I've got to say on this
  > topic. Happy holidays...
  > 
  > 
  >                 jak
  >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 20 Dec 2001 18:58:04 +0100

=> Ok, well I don't think it's a tangent at all. 
The point here is that you can't change your 
default router based on advertisements, how 
do you know whether your traffic will be accepted
and not dropped by the FA ? 
In fact you don't know if you've moved at all. 
A new FA might have simply appeared on the 
same link. 

Anyhow, Karim has already shown text from
2002 to explain this.

There is nothing wrong with finding bugs in 
implementations, I don't know why it's been 
taken as an insult and brushed away. 

  > 
  > More importantly, it did NOT affect the performance results 
  > we got. I'd be
  > happy to discuss the details more, but let's take it 
  > offline for now.
  > 

=> Assuming movement (and implicit registration
and reply to the nFA) just because a new FA
advertisement is received, will clearly have 
an impact on performance. This is the implication
of resetting your default router based on new 
FA advertisements. 
That is one of my points against your paper, and 
honestly, after writing all these emails to your 
co-author, I'm looking forward to my holidays 
tomorrow so if you want to discuss more then let's 
do it next year :)

Hesham

  > Jonathan