Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft

From: [email-masked]
Date: Mon, 25 Feb 2002 16:47:30 -0600

Bechet,
You are stretching your interpretation of my mail and presenting as my views.

1. There may be a solution that fits all. I am not against it. But who wants to use simple-ip? "Independence to mobility protocol" was a key point in decision making, as indicated in the paging-assessment draft.  Paging protocol is most likely will always be used with mobile devices, hence the successful and wide acceptance of paging protocol depends on a solution that takes more of mobility into consideration. Sacrificing this point may well make the final paging protocol not so useful, at best.

2. I am not particularly inclined for HA based solutions. My point is, while defining a mobility based paging protocol we should not take a particular LMM method (for e.g. HMIPv6) as  solution, like draft-sarikaya. But instead a generalised LMM approach. HA based solution will also be needed for non-LMM cases.

Srini

-----Original Message-----
From: ext Behcet Sarikaya [mailto:[email-masked]]
Sent: 25 February, 2002 9:32 AM
To: [email-masked]
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft

Dear all,
  Several mails have been sent over the weekend I'll try to give my 
views in one mail.
Regarding Srinivas' email, my understanding is that he is against 
Alternative 1 (one size fits all solution) and he is for the Alternative 
2. In that he is suggesting that we concentrate on Requirement 4.8 
rather than 4.7. As for the drafts, he seems to be inclined to home 
agent based architectures which is demonstrated in draft-renker. This is 
an architectural choice, I think that his choice of alternatives is clear.
  Besides, I think that the chairs would like to choose draft/drafts as 
soon as possible and ask people to submit their 01 drafts by March 1st 
and move on. We do not have a lot of time for doing this.

Regarding Yoshi's email, I am quoting the abstract of RFC 3103:

> This document presents a protocol with which to implement Realm
>    Specific IP (RSIP).  The protocol defined herein allows negotiation
>    of resources between an RSIP host and gateway, so that the host can
>    lease some of the gateway's addressing parameters in order to
>    establish a global network presence.  This protocol is designed to
>    operate on the application layer and to use its own TCP or UDP port.
>    In particular, the protocol allows a gateway to allocate addressing
>    and control parameters to a host such that a flow policy can be
>    enforced at the gateway.

Yoshi, I think that the functionalities summarized above of RSIP have 
nothing to do with IP Paging. Can we define a port specific to  IP 
Paging , if yes then how does IP Paging capture all packets to the 
dormant hosts?

Added to this, please see Pars' email,

>This is serious, because "paging" which is intended for
>optimizing bandwidth use, may become a bandwidth threat.
>IP layer solutions may be necessary. This is, perhaps, one more motivation for IP paging.
>

Let us get motivated for IP Paging.

Regards,

[email-masked] wrote:

-- 
Behcet 

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Feb 2002 17:07:41 -0600

Hi Srinivas,
  My comments in line.

>You are stretching your interpretation of my mail and presenting as my views.
Apologies if so.

>1. There may be a solution that fits all. I am not against it. But who wants to use simple-ip? "Independence to mobility protocol" was a key point in decision making, as indicated in the paging-asse…
Agreed. As a matter of fact this was what I argued during requirements 
draft development phase, I was against Requirement 4.7. I am sure Jim, 
Yoshi and other colleagues will remember this. By having both 4.7 and 
4.8 as requirements confused people in thinking that one size fits all 
solutions can be developed.

>2. I am not particularly inclined for HA based solutions. My point is, while defining a mobility based paging protocol we should not take a particular LMM method (for e.g. HMIPv6) as  solution, like…
May I disagree on this? LMM is not Seamoby protocol. Alternative 2 is 
stating clearly that we follow the developments in Mobile IP WG and 
align Seamoby paging protocol with the LMM of choice in MIP WG. This 
creates a dependency. We already have a dependency by using MIP. What is 
wrong with another one?

Regards,

--bechet

---

From: Vinod Kumar Choyi <[email-masked]>
Date: Mon, 25 Feb 2002 18:13:58 -0600

Srinivas,

Mobile devices  (that do not have any home or do not use MIP)could also 
use just Simple IP, but I agree with you that the emphasis should be 
more on mobility.

regards
vinod

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Feb 2002 15:56:45 -0800

Srini/Behcet,

This sounds like a rehash of the requirements discussion. We have the
requirements, and we have a couple of possible approachs to meet them.
Let's move on...

            jak

----- Original Message -----
From: "Behcet Sarikaya" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 25, 2002 3:07 PM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft

> >1. There may be a solution that fits all. I am not against it. But
who wants to use simple-ip? "Independence to mobility protocol" was a
key point in decision making, as indicated in the paging-assessment
draft.  Paging protocol is most likely will always be used with mobile
devices, hence the successful and wide acceptance of paging protocol
depends on a solution that takes more of mobility into consideration.
Sacrificing this point may well make the final paging protocol not so
useful, at best.
> >2. I am not particularly inclined for HA based solutions. My point
is, while defining a mobility based paging protocol we should not take a
particular LMM method (for e.g. HMIPv6) as  solution, like
draft-sarikaya. But instead a generalised LMM approach. HA based
solution will also be needed for non-LMM cases.

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 26 Feb 2002 22:40:50 +0000

Hello all,

May I suggest that I would find personally unfair to go ahead with a
selection of a single solution since _none_ was satisfying in absolute
terms specific marks required for a weighted consideration as an WG
item. I personally stated the following in the evaluation team which I
would just reiterate: at this stage no protocol must be selected amongst
all. Having read all drafts I feel that none is fittest than another. I
am also talking as an evaluator that has no interest in any of them in
terms of selection. Right now the authors of the drafts needed to go
back on their drawing board and consider the comments that the
evaluation team gave (hence the output draft). The authors must rework
their solutions in the light of these comments.

A last round of evaluation must then be carried out by the same team
since it already has the initial view of the problem. A final decision
must be taken past the last changes and amendments of the DHMA protocol
solutions, which must not be disputed by anybody under objective
criteria and no arguments against the evaluators that they missed this
or did not see that. 

The results from the review would then come up as a revised draft and in
public scrutiny to the interested individuals that must be considered
objectively (no company hats) if we ever want to see something moving
forward. If the results from the criteria pass a last call from the
community then the chair will announce the protocol that dominates
overall in marks. Then we proceed and take it further.

Alternatively the authors of the draft get together and they build a
single protocol by unifying the concepts that the evaluation team found
to stand out from each proposal. The authors converge and bring their
elements together in a single solution that is decided if to be
independent of any mobility protocol or not.

The chair declares a concensus on the matter, a single protocol is
defined and considered an WG item. 

We can then proceed in peace and evolution of the DHMA solution.

Please consider..

regards

Theo
UCL/Mobile Systems

Vinod Kumar Choyi wrote:
> 
> Srinivas,
> 
> Mobile devices  (that do not have any home or do not use MIP)could
> also use just Simple IP, but I agree with you that the emphasis should
> be more on mobility.
> 
> regards
> vinod
> 
> > who wants to use simple-ip? "Independence to mobility protocol" was
> > a key point in decision making, as indicated in the
> > paging-assessment draft.  Paging protocol is most likely will always
> > be used with mobile devices, hence the successful and wide
> > acceptance of paging protocol depends on a solution that takes more
> > of mobility into consideration. Sacrificing this point may well make
> > the final paging protocol not so useful, at best.
> > is, while defining a mobility based paging protocol we should not
> > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > From: e
> > xt Behcet Sarikaya [mailto:[email-masked]]
> >   Besides, I think that the chairs would like to choose draft/drafts
> > a
> > s

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Feb 2002 18:20:50 -0600

Hello Theo,
  Good to hear from you, the last evaluator has finally spoken out.

My only comment is that your assumption of a single solution 
unfortunately does not consider the discussion on Requirements 4.7 and 4.8.

If there must be several DHMA protocols to be developed, you still would 
recommend that we go through the formal procedure you outlined for each 
separately?

People will say may be it is too much.

Regards,

>We can then proceed in peace and evolution of the DHMA solution.
--behcet

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 27 Feb 2002 01:21:11 +0000

Hello Bechet !

I wanted to see what the constituency felt about the selection process
and to be honest I was not far at all from my initial feeling. This is
not a AD prophesy sort of thing..

My recommendation for a single joint solution must be viewed in the
light of the following: We need to be specific what is meant by 4.7 i.e.
independence from Mobility protocols. Does that even include base
mobility?

What I would not like to see is reinvention of mechanisms that are
already in place for mobile IP..pretty much like static binding of
libraries in binary executable as opposed to a dynamic one...the first
solution is fatter but can stand on its own...so we need to be careful
with what is really meant independent...but _still_ lightweight..

Of course 4.8 means that you can support it but can obviously live with
out it. If it supports a mobility protocol it means that it can plug in
it, give it the information of interest and then hook off without
breaking the mobility protocol. The authors are advised to consider how
well do they do that in their solution.

Dependency on an LMM mechanism is a bit dangerous..if people expect to
enforce LMM to get paging working...I think it would be a long shot this
one..it is important to differentiate whether the proposal uses the idea
of localisation as opposed literally an LMM agent. If the two notion can
be co-located in a single entity..so the better..it fullfills also
4.8...but it must strive to satisfy 4.7 or it becomes a contradiction in
requirements.

The procedure that I outlined if we are to urge the author to go back
and revisit their designs implies that the authors have a finite time to
reconsider their designs in the face of the team recommendations. The
team will have a second round of reviews and if then the proposals stick
to the same incosistencies they will unfortunately have to be ruled
out.. unless they have strong grounds to stick to their guns..but the
constituency needs to see that ..

So we are not going to take each protocol in turn in the list and
analyse/paralyse it. The team will have to review them again and on
these ground come to a conclusion with respect to satisfying the
requirements. Since there is more than one solutions the competition is
stiff and of course there is no bending of the criteria...like "seems
good but will get better later on.."

I personaly do not believe it is too much. In fact if I consider the
bandwidth spend on the deliberations about which DHMA proto and why...I
believe we would have finished by now... :)

cheers

Theo
UCL/Mobile Systems