[Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hi Pete,

> 
> Hi, Ahmad,
> 
> Ahmad Muhanna wrote:
> >> If we can increase the timer so that 99% of the time the 
> registration 
> >> completes (or fails) within the new timeout value, then we 
> will have 
> >> the initial RRP back to the MN before it retransmits (or, 
> in the case 
> >> of failure, the retransmission will be really necessary).  
> This seems 
> >> to solve the issue.  I don't think we should go re-architecting the
> >> MIP4 Diameter application because of a mismatched timeout value.
> > 
> > [Ahmad]
> > Ok, I think this is an important step. I think what you are 
> trying to 
> > say is that you agree with the analysis that the draft 
> presented and 
> > you are trying to propose solutions for the issue without 
> any change 
> > to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair
> > statement?    
> 
> I agree that if the Diameter infrastructure takes too long to 
> respond to the MN before it retransmits, this would 
> potentially put a second, uneccessary AMR into the network, 
> causing more traffic.  The registration process itself would 
> be delayed a bit because the MN would be waiting for a 
> response to its most recently transmitted RRQ.  However, 
> RFC3344 specifies an exponentially increasing timeout value 
> so eventually the MN would get registered.
> 
> I think that summarizes the problem you raised; it could have 
> been sent to the list in that form rather than writing an 
> entire draft with call flows comparing RADIUS to Diameter.

[Ahmad]
I assume you are talking here with MIPv4 chair hat-off, there is no
restrictions about writing drafts in IETF and getting two wg to agree to
present the idea and generate discussion inside the meeting and on the
mailing lists or you are suggesting a new IETF rule here?

Having said that, I guess the least which can be said about what you
just mentioned is over simplification of what the draft is trying to
present. The idea the draft was to highlight and present, IMO and many
others, a valid weakness about D-MIPv4 architecture. The draft is trying
to compare the performance of the current RADIUS deployment to what to
be Diameter Mobile IPv4 Application deployment. Let me try to explain
what the draft is trying to highlight one more time:

1. Currently there are certain deployment configuration parameters and
the operator probably would like to get better performance in case
Diameter is used in place of RADIUS without further studies and analysis
to how to tweak the network in order to optimize the expected D-MIP4
performance issue.

2. The point here is not about Diameter as an AAA protocol, however, it
is about the concept of coupling the MIPv4 control signaling to AAA
signaling. Which many people do not think it is a good idea and believe
that it is a deviation from RFC3344 initial MIPv4 registration
procedure. Do not you agree?

3. Of course, RFC3344 have a retransmission mechanism, which in most
cases should get the MN eventually registered. On the other hand,
RFC4004 proposes a Diameter Application and impeded MIPv4 control
signaling inside AAA control signaling and the draft never assumed that
there could be an impact on the MIPv4 signaling retransmission mechanism
or performance. Not to mention coupling of MIPv4 signaling
retransmission with AAA signaling retransmission.

4. If the AAA infrastructure have the same load in case of RADIUS and
D-MIP4 and the MN had to retransmit the initial MIPv4 RRQ, there is a
much much greater chance that D-MIPv4 will cause another round of
UNNECESSARY AAA signaling that does not happen in the case of RADIUS.

5. If the AAA infrastructure is slightly loaded and cause a MN to
retransmit its MIPv4 initial RRQ, D-MIPv4 as per RFC4004 makes the
situation much WORSE by injecting, at least, DOUBLE the number of AAA
(Diameter) signaling messages. In the case of RADIUS this is not there.

6. Actually, we are going to publish a new revision of this draft and
address the scenario of allocating a HA in the visited network. Have you
looked into the difference between the RADIUS and D-MIP4 performance in
this scenario and what will happen if the MN happened to retransmit?

7. Finally, I guess all of the above worth writing a draft in order to
provide heads up for the industry of what to expect in case D-MIPv4,
RFC4004, is deployed in place of RADIUS.

> 
> I agree that a Diameter (or RADIUS, for that matter) 
> infrastructure might take more than 1 second to respond to an 
> AMR or an Access-Request.
> It seems that the solution is to recommend a longer timeout 
> value for the initial retransmission.  Another solution would 
> be to allow the MN to complete its registration successfully 
> by receiving an RRP matching a previous RRQ (not just the 
> most recently retransmitted one).
> 
> I don't think we should turn the MIP4 Diameter application 
> into a 2-round-trips protocol.  The goal of RFC4004 is to 
> provide MIP registration in one round-trip.
> 
> -Pete
> 


--
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/