Subject: [Seamoby] comments on the paging protocol assessment draft

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Dec 2001 19:05:42 -0500

I have a couple of comments to the paging assessment draft
(draft-ietf-seamoby-protocol-assessment-00.txt).

First thing is the process of selection. The criteria for selection
from the proposals, and the result should be included in the
assessment draft.  Specifically, the selected protocol is the one
having the largest number of the lowest ratings, i.e., containing six
1's, and neither having the largest number of the highest ratings nor
having the highest avarage rate.  There is a logical leap between the
ratings and the final selection. So I think that selection team had
some criteria other than the ratings.

And the second thing is that the comments that were posted by some of
the authors of the candidate protocols before the SLC meeting should
also be reflected to the assessment draft, if those comments are
relevant.

Regards,
Yoshihiro Ohba

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Dec 2001 11:35:05 -0800

Yoshi,

> some criteria other than the ratings.

Yes, this wasn't clear. As I believe was discussed on the list, the
final decision was not made by the selection team, it was made
in consultation between the WG chairs and our AD. We based
our decision on the selection team's assessment and recommended
course of action(s). There was a judgement call involved, and the
judgement was based to a certain degree on what requirements
we felt were most important, in addition to process considerations.

In particular, as I mentioned in my previous email to Behcet,
independence
from mobility protocol was considered a first priority requirement,
because
this has been a foundational principle of all Seamoby work. In addition,
we
did not want the protocol to be encumbered by or dependent upon the
process of another working group, as this would set up a dependence
between our work and the work of another working group that could
result in delays. Finally, requirements originating out of the problem
statement
had higher priority than other requirements. So, for example, the
requirement of indepenence of paging area from subnet topology
was identified in the problem statement and therefore had higher
priority. These requirements are ones that we believe will give IP
paging
an advantage over current practice, and therefore are likely to serve as
an
incentive for implementation and deployment.

> also be reflected to the assessment draft, if those comments are

The assessment is meant to be a record of the assessment team
deliberations
and not a complete transcript of the working group's dialog on the
process.
The comments posted by the authors are part of the mailing list archive.

However, I should probably remove the sentence in the abstract that says
the assessment draft will make a recommendation, since it doesn't.

Thank you for posting this. It is very important that the decision
making process
be transparent, and I agree that the WG chairs have not done a very good
job of explaining it. I hope this makes things clearer.

                jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Dec 2001 15:36:45 -0500

Jim,

Thanks for the response.

Additional comments are in-line.  Note that I'm not objecting the
selection since it would be better to be constructive, but just to
make things clearer and have a correct understanding of the result 
as much as possible.

> this has been a foundational principle of all Seamoby work. In addition,

As assessment team correctly evaluated,
draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies independency
from mobility protocol.

> incentive for implementation and deployment.

draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies indepenency of
paging area from subnet topology, but unfortunately the selection team
seems to misunderstand that the protocol does not satisfy this
requirement, which I also pointed out this both on the mike in the SLC
meeting and in my comments posted before the SLC meeting.  Actually,
we paid a special care on this point, for example we explitly
mentioned in the draft that:

   Paging Area

     (snip)

     An arbitrary mapping between subnets and paging areas is allowed in
     this protocol.

Additional comments:

Jim also mentioned in the SLC meeting that our protocol requires
extranous signaling (among separate agents), which is not desirable.
This is not exactly correct because our protocol allows elimination of
extranous signaling by implementing those agents in a single box (for
small size networks).  Extranous signaling is inevitable if
scalability matters.  For the same reason, extranous signaling is also
described in the selected protocol if PA is hierachically configured.
There is always tradeoff between scalability and centralized agent.

Jim also mentioned in the SLC meeting that our protocol does not
support time-slotted dormant mode at L3.  This is true, but
time-slotted dormant mode at L3 was not explicitly described in the
requirements document, and I don't think the basic issue of how to
synchronize at L3 can be solved by just definig a set of
synchronization timing parameters.  Additional consideration of
hardware-based IP-paging implementation and interference with other
traffic, etc. would be still necessary if we really want to archive
it.

Regards,
Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Dec 2001 15:00:21 -0800

Hi Yoshi,

> make things clearer and have a correct understanding of the result

I understand.

> draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies independency

Yes.

>      An arbitrary mapping between subnets and paging areas is allowed
in

But do you think it is realistic to expect the paging team to rate
the design based on this single sentence when the name of the protocol
implies a connection between the subnet and paging area, and the
rest of the design is described in terms of having a paging agent (which
controls the paging area) in the last hop subnet?

> There is always tradeoff between scalability and centralized agent.

Exactly what functional elements to group into a network element
is a design, not an implementation, choice. The draft-ohba design chose
a one to one mapping between functional elements and network
elements. While it is certainly possible to deploy by bundling
multiple network entities on a single host, the interface between
the entities, and thus the protocols on those interfaces, remain
as does the potential for extraneous signaling.

That said, I agree that it is certainly a challenge to come up with
a design that minimizes signaling, and I think that, going
forward, we need to keep this in mind.

> traffic, etc. would be still necessary if we really want to archive

The requirements do call out the need to support multiple dormant
modes, and that requires the ability to support time-slotted paging.
For example, draft-sarikaya has a good description of how
to support time-slotted paging. I recall having discussed this
in the requirements phase, but perhaps we should have been
clearer in the requirements document about what support for multiple
dormant modes means.

            jak

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 21 Dec 2001 15:29:13 -0800

Hello,

Seems I have mail problems (James's mails get filtered due to
them having "MIME EXPLOIT - multiple CTE flds", local problem here..)
I do not know if paging-protocol-assessment has been to last call and
have this comment whenever that is the case.

I have to agree with Yoshihiro's remarks and suggest the following.
Seems the paging assessment team's draft does not map at all to the
actual selection criteria and no textual document on the actual
criteria have been published in a working group document format.
Hence the current assessment document does not represent the decision
and I can't see what is its usefulness as an RFC.

From the mails so far there seems to be no clarity on preference
of criteria and how the important one really map to current proposals.
I read from fragments of James's mails protocol independence and
topology independence are good but fail to see why this would make
draft-renker clearly above other than on hmip-paging on protocol
independence. Hence, I suggest a re-write of an assessment document
explaining the process and criteria by which draft-renker was selected.

BR,

-Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Dec 2001 18:02:44 -0500

> controls the paging area) in the last hop subnet?

We also have the following desription:

6.4.3.  Other States in Paging Agent

   The following additional information MAY be maintained.

   o A list of Access Routers through which Paging messages are carried
     on traffic channel.

   o Any L2 dependent information needed for performing L2 paging.  The
     L2 dependent information MAY include the list of Access Points that
     are not able to receive and process Paging messages at L3.  Note that
     how to page Hosts through those Access Points depends on L2 and out of
     the scope of this document.

     /* Authors' note: if an Access Point is able to receive and process
     Paging messages at L3, then it can be a separated Paging Agent and
     SHOULD NOT be included in the above list. */

I think this is enough to indicate independency between paging area
and subnets.

> as does the potential for extraneous signaling.

It would be more fair to say that draft-renker also remains as does the
potential for extraneous signaling since it defines hierarchical
paging, but the degree of extraneous signaling of draft-renker 
might be less than that of draft-ohba since DMA and TA is always 
together in draft-renker.

> forward, we need to keep this in mind.

Agreed.

> clearer in the requirements document about what support for multiple

I misunderstood the meaning of multiple dormant modes such that it
would mean multiple dormancy states, e.g., Active/Sniff/Hold/Park
modes in the case of Bluetooth.  Also, I had been thinking that
time-slotted paging at L3 only relates to the following requirement,
and that it is weaker than other requirements since it uses SHOULD NOT
instead of MUST NOT.

4.13.   Future L3 Paging Support
   
   Recognizing that future dormant mode and wireless link protocols may 
   be designed that more efficiently utilize IP, the IP paging protocol
   SHOULD NOT require L2 support for paging.

I guess this requirement seems to have been weighted higher during the 
judgement process.

Yoshihiro Ohba

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 21 Dec 2001 16:46:58 -0800

Hello,

Having a design team framework document is ok, currently the draft-renker
gives a multitude of choices to do a protocol. Ultimately we'll need something
simple and unambiguous. This would need strong modification to become a
real protocol from its current format which looks more like an architecture
with candidate modes for several functionalities.

I second that the requirement for protocol independence is important.
Hence, I suggest structuring the document in a way that decouples the protocol
from all other protocols (MIPv6 etc. included) so much that they do not need
ideally to be even refered to at all. If needed, there should be appendices
describing interaction but only in the case it is essential for the
working of the protocol in some mode etc. Interdependences should be
minimized.

Merry Christmas and a Happy New year all,

-Jari

On Fri, Dec 21, 2001 at 06:45:59PM +0100, Marco Liebsch wrote:
> Dear all,
> I will try to structure a draft framework, which is then for discussion
> on the list, taking first the protocol as it is now and moving the
> Mobile IPv6 options to be considered for MIP optimization purposes into
> the Annex (open). We have to think about extensions and address the
> parts the assessment draft refers to. Until first framework is
> available, please be referred to the current version of the base-line
> concept draft-renker-paging-ipv6-01.txt and also think of issues to be
> clarifed with respect to what is already written. So we can address
> these issues and have enhancements in the first draft version, which
> could be submitted end of January, if the WG agrees and we proceed. What
> do you think?
> 
> I wish you all a merry Christmas and a happy new year. I will be back in
> the office around Jan, 10th.
> 
> Marco
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Dec 2001 21:41:38 -0800

Jari,

Good points. I will add a section in the assessment document that
explains how the final decision was arrived at.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Dec 2001 22:03:08 -0800

Yoshi,

> I think this is enough to indicate independency between paging area

I agree that the first bullet implies that there may be multiple
subnets per paging agent, and thus per paging area,
but to me this looks like an afterthought
and not a fundamental feature of the design. I expect that was
also the case for the person who performed the requirements
comparison on the document. It was difficult enough for
the assessment team to wade through the details of
each protocol in the alloted time. I don't think one can expect that
they should infer that a requirement is satisfied based on
a few hints here and there. If a requirement is intended
to be satisfied, then it should be clearly stated how. At
best, this bullet and the previous statement would
rate as a rather deep underspecification on this
requirement.

> I guess this requirement seems to have been weighted higher during the

It was not a first priority requirement, but it was deemed important.
As I said in SLC, we went through a process of normalization
on our comparison criteria, and some proposals ranked higher
on certain requirements than others.

Would you find it satisfactory if, as Jari suggested, some text
is inserted into the assessment draft explaining how the final
decision was made?

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 22 Dec 2001 11:00:10 -0500

Jim,

I understand the reason of the ratings for draft-ohba on the
requirements that were said to be focused during the judgement phase.

But it is still not clear why draft-renker is selected even based on
the focused requirements, since the rating for draft-renker on each of 
those requirements are not the highest (see below).  

   |------------|------------|-------------|-------------|------------|
   |            | Ref. [3]   | Ref. [4]    |    Refs.    | Ref. [5]   |
   |            |            |             |-------------|            |
   |            |            |             | [6]     [7] |            |
   |------------|------------|-------------|-------------|------------|

   (snip)

   |    4.6     |            |             |             |            |
   | Multiple   |            |             |  4/2     1  |            |
   | Dormant    |    2       |     1       |             |     2      |
   |  Modes     |            |             |             |            | 
   |------------|------------|-------------|-------------|------------|

   (snip)

   |    4.7     |            |             |             |            |
   |Independence|            |             |  1       4  |            |
   | of Mobility|    4       |     3       |             |     4      |
   | Protocols  |            |             |             |            |
   |------------|------------|-------------|-------------|------------|

   (snip)

   |    4.12    |            |             |             |            |
   | Orthogonal-|            |             |  4       4  |            |
   | ity of PA  |     4      |     1       |             |     2      |
   | and subnets|            |             |             |            |
   |------------|------------|-------------|-------------|------------| 

   (snip)

Yes.

Thanks,
Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Dec 2001 13:15:53 -0800

Yoshi,

>    |            |            |             |-------------|
|
>    |            |            |             | [6]     [7] |
|
>    |    4.6     |            |             |             |
|
>    | Dormant    |    2       |     1       |             |     2
|
>    |  Modes     |            |             |             |
|
>    (snip)

As I mentioned, this was not a top priorty requirement and was
not discussed during the decision phase. However, if you
want an opinion, as the assessment draft stated, draft-ohba
tied support for multiple dormant modes to 802.11 power
management, a specific link layer type, in Appendix A.
Draft-renker had nothing on this requirement, as the assessment
indicated.
What the requirement was really getting at was support for
time-slotted paging, and perhaps the requirement wording should have
been
more clear in this respect. Draft-sarikaya did an excellent job of
discussing time-slotted paging, but, unfortunately, as I discussed in
my response to Behcet, the entire design was predicated
on a protocol that was not yet through reqirements phase in
another working group. Something like the time-slotted
paging support in draft-sarikaya is what is needed in
the final protocol.

As a metacomment, this requirement represents exactly the
difficulty that the assesement team and the decision
team had with regard to selecting one of these drafts
as the basis for further work. Each draft had particular
aspects of it that were well thought out and recommended
themselves for inclusion in the final result, but none of
the drafts exhibited the maturity of implementation
and design that immediately suggested it as
the only possible candidate for selection, and some drafts had
particular aspects that mitigated strongly against
selection.

>    |    4.7     |            |             |             |
|
>    | Protocols  |            |             |             |
|
>    (snip)

In this case, draft-renker was viewed as having overspecified the
requirement.
Overspecification is not necessarily negative, since getting it to
match the requirements means that things only need to be taken out, and
that may often simplify doing a final design, because the choices and
their consequences are clear, whereas, if a single choice is presented,
the consequences of the rejected choices may not be so clear. Of course,
other things being equal, a design that exactly meets the requirements
and exhibits the kind of maturity of design and implementation
mentioned above is preferable.

>    |    4.12    |            |             |             |
|
>    | and subnets|            |             |             |
|
>    (snip)

The justification for the classification given to draft-renker
on Requirement 4.12, the orthogonality of PA subnets (pg. 8 of the
assessment draft)
indicated to me that the rating of 1 was unfair. The justification has
to
do with an obscure use of the TMSI for paging. Perhaps this was a typo
or
something the assessment team overlooked in the process
of performing the normalization. As the diagram on pg. 13 of
draft-renker
clearly shows, the protocol is designed to support mapping of
multiple subnets to a paging area, which is controlled by the paging
agent.
This is in contrast to draft-ohba, where support for multiple
subnets was only briefly mentioned, almost as an afterthought.
At worst, draft-renker rates a very strong 2 on this requirement.

> > is inserted into the assessment draft explaining how the final

I will attempt to come up with some text that describes
the decision phase.

            jak