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

[Yoshihiro Ohba <[e-mail]>]

On Fri, Dec 21, 2001 at 03:00:21PM -0800, James Kempf wrote:
> Hi Yoshi,
> 
> > 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.
> >
> 
> I understand.
> 
> > As assessment team correctly evaluated,
> > draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies independency
> > from mobility protocol.
> >
> 
> Yes.
> 
> > 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.
> >
> 
> 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?

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.

> 
> > 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.
> >
> 
> 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.

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.

> 
> 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.

Agreed.

> 
> > 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.
> >
> 
> 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.

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


> 
> 
>             jak
> 
> 

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