Subject: [seamoby] comments on paging assessment draft

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Nov 2001 22:16:41 -0500

Thanks to the DMHA protocol evaluation team for their excellent job of
producing a useful document.  I think the assessment is reasonable
considering the fact that the work had to be done in such a limited
time period.

Here I have some comments for the assessment on our protocol (please
search "$ohba" for my comments).

Regards,
Yoshihiro Ohba

------------------------------------------------------------
  4.4    draft-ohba-seamoby-last-hop-dmha-02.txt 
    
   The following requirements were not fully met by draft-ohba-seamoby-
   last-hop-dmha-02.txt: 
   _ 
   Requirement 4.1:  Power Consumption 
    
   Registration to the TA through the DMA may not be optimal in terms 
   of power consumption, since a DMA Reg-ACK cannot be returned to the 
   host until the TA acknowledges the proxy registration request. 
   However, since the author also specified the direct communication of 
   the host with the TA, this requirement is overspecified to the 
   degree that can detract from efficiency. 

$ohba: 

I think there is of no difference in power consumption as to
whether the paging registration operation (not the paging area update
operation) is performed directly with the TA or indirectly via DMA,
because even if the direct registration were performed during the
paging registration operation, TA Registration ACK cannot be returned
until the TA successfully performs DMA registration with the DMA.

On the other hand, direct TA Registration would be useful 
in the case of paging area update operation, in which case 
TA Registration ACK can be returned immediately because DMA already 
has DMA state for the Host at the time of paging registration operation.  
That is the reason for defining the direct communication of 
the host with the TA for paging area update operation only.  

Note that paging area update operation can also be performed
indirectly via DMA.  Altough this may not be optimal in terms of total
number of message exchanges, but this would be useful if the Host 
wants to have only one security association with DMA, instead of 
two security associations, one with DMA and the other with TA.

   _ 
   Requirement 4.2: Scalability 
    
   The protocol tends to describe its operation with one DMA per link, 
   one TA (primarily) and multiple PAs, as shown in Figure 3. When the 
   protocol suggests that more than one TA can be present and each one 
   manages a specific set of hosts, it fails to specify how this is 
   achieved. 

$ohba: 

I agree that more description is necessary for how the protocol
operates with multiple-TAs.
    
   Requirement 4.4: Efficient Signaling Inactive Mode 
    
   The protocol underspecifies the requirement because it suggests that 
   successive paging operations are to follow a paging interval that 
   increases exponentially, but does not specify an initial and final 
   value that the exponential figure is allowed to reach. Is it 
   persistent in the paging retry? Does it time-out at all?  

$ohba: 

I assumed the latter.  The state for inactive hosts would be deleted
when DMA registration lifetime expires.  We could also have
another final value which is smaller than the DMA registration
lifetime for exponential backoff.

   _ 
   Requirement 4.6: Multiple Dormant Modes 
    
   The type of dormant modes that the protocol attempts to support is 
   based on a particular technology, while the protocol does not affect 
   the operation of the MAC layer at all. While one can claim that the 
   protocol combines L2 power saving features that contribute to power 
   conservation, this is not owed to or couple with the proposed 
   protocol. It is simply a manifestation of power savings through 
   special forms of MPDU scheduling. Any protocol can claim such 
   cooperation. Important aspect of dormancy like slotted dormant for 
   non-L2 layer has not been considered by the protocol. 

$ohba: 

Right, time-slotted dormant mode at L3 is not supported yet, I think
we still need more investigation on how accurate synchronization is
realized at L3, which would be required to support time-slotted
dormant mode at L3.
    
   Requirement 4.12: Orthogonality of PA and Subnets 
    
   The description of the protocol, although it mentions paging areas, 
   does not specify clearly how this is achieved since there is no 
   specific description of how the page message diffuses over an 
   topology of multiple subnets that are controlled by a single PA. 

$ohba: 

When a PA takes care of multiple subnets, there would be two cases.
If L2 paging is available, the PA just kicks L2 paging for the set of
L2 paging areas that covers the subnets.  On the other hand, if L2
paging is not used, all the ARs of those subnets should join the
multicast group which is used for carrying Paging messages, and the PA
multicasts the Paging messages to that multicast group address.  Each
AR then just forwards the multicast Paging messages on to its last hop
subnet(s).

I agree that this kind of description is missing in the document.  

   _ _
   Requirement 4.14: Robustness against Failures
    
   While the protocol specifies keep-alive signals between the peer 
   agents, it does not specify a scheme that allows recovery from 
   failure.  
   _ 
   Requirement 4.15: Reliability of Packet Delivery 
    
   The transport used in this protocol is UDP. The protocol does not 
   describe how the packet is forwarded to the host. In particular, it 
   does not describe what is the situation when the packet received at 
   the DMA is TCP. 

$ohba: 

TCP would not be an appropriate DMHA message carrier.  One reason is
that in some cases DMHA messages are multicast.  Another reason is
that the CoA of a Host may change while it is in dormant mode (and it
does not perform mobility binding update), in which case the Host
would use CoA for DMHA protocol exchanges but if TCP is used the TCP
connection would get lost after the CoA change.  Another reason is
that if a large number of Hosts are dormant, then the DMA would have
to maintain a large number of TCP connection states with dormant
Hosts, which would consume OS kernel memories at the DMA.

   _ 
     
   Requirement 4.17: Administrative Flexibility 
    
   The configuration of the paging areas is not quite automatic as 
   claimed. In particular the protocol does not specify how the page 
   area identifiers are assigned/allocated such that they can be 
   distributed to the individual paging agents.  
   _ 
   Requirement 4.18: Flexibility of PA Design 
    
   With respect to the claimed flexibility, the design is not clear in 
   Fig. 3. The TA propagates paging requests, why? 

$ohba:

There is a design choice as to whether the TA acts as a relay agent or
redirect agent for the Paging messages.  If TA acts as a redirect
agent, then it would not scale well if we assume the number of DMAs
and PAs are much larger than that of TAs, because each DMA has to have
a security association for each PA or for a set of PAs to send Paging
messages directly from DMA to PAs.  That is the reason for defining
the TA as a relay agent.

   _ 
   Requirement 4.19: Availability of Security Support 
    
   The protocol does not support encryption services. It only supports 
   authentication. For ESP security, it relies on mechanisms such as 
   IPsec.  

$ohba: 

Right. As I mentioned in the recent thread "DMHA and IPsec", IPsec
would not be appropriate for DMHA.  On the other hand, defining an
encryption mechanism is tough.  I think a PBK-like common security
mechanism which uses stable identifier for identifying a Host would be
really desired.

   In addition, the following general concerns were expressed about the 
   protocol design: 
    
     1) The protocol utilizes the DMA like the TA in the functional 
        architecture draft, but does not specify a method for the DMA 
        to discover an appropriate TA. The assumption seems to be that 
        there will be a single TA per administrative domain or multiple 
        TAs with the TA to DMA mapping manually configured.  

$ohba:  

The current assumption is latter.  

     2) The protocol assumes the dormant host can detect a paging area 
        change, which implies that time-slotted paging must be used if 
        there is no L2 paging channel support. However, the protocol 
        does not explicitly mention how it would support time-slotted 
        paging. 

$ohba: 

Please refer to my comments on Requirement 4.6.

     3) The proxy interactions between the DMA and TA on behalf of the 
        dormant host incur extraneous signaling and may lead to 
        inefficient power consumption.  
 
$ohba: 

Please refer to my comments on Requirement 4.1.

     4) The assumption that the DMA is located on the last hop subnet, 
        which is the foundation of the design, means that the PA is 
        unnecessary, and links the paging area directly to the subnet. 

$ohba:

I think there is some misunderstanding here.  DMA is assumed to be in
last-hop subnet because it is the place where any packet destined for
the dormant Host always reaches, but PA should be put anywhere and is
necessary, given that the relationship between subnets and paging
areas is orthogonal.

     5) The protocol specifies heartbeat messages between agent peers. 
        This method can identify a failed agent, but it cannot specify 
        how to recover from failure. 
 
     6) The protocol does not specify how a host chooses between DMAs 
        nor how a DMA chooses between TAs. 

------------------------------------------------------------