Subject: [Pana] issue 57 (resolution)

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 16 Mar 2004 15:18:13 -0800

This is the resolution for issue 57 (PSR retransmission strategy).
Basically the same as what I had proposed on the mailing list in
February and presented in the IETF59 meeting.  Further comments are
appreciated.

- Change the following paragraph in section 

"
   A PANA-Start-Request message is never retransmitted. A
   PANA-Start-Answer message is retransmitted based on timer in the same
   manner as other messages retransmitted at PANA-layer.
"

to:

"
   A PANA-Start-Request message that carries a Cookie AVP is never
   retransmitted.  A PANA-Start-Request message that does not carry a
   Cookie AVP is retransmitted based on timer.  A PANA-Start-Answer
   message that carries a Cookie AVP is retransmitted based on timer.
   A PANA-Start-Answer message that does not carry a Cookie AVP is
   never retransmitted based on timer.
"

Change the first paragraph of section 10 to:

   "The PANA protocol provides retransmissions for all the message
   exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages
   carry EAP requests which are retransmitted by the EAP protocol
   entities when needed. The messages that need PANA-level
   retransmissions are listed below:

         PANA-PAA-Discover (PDI)
         PANA-Start-Request (PSR)*
         PANA-Start-Answer (PSA)**
         PANA-Bind-Request (PBR)
         PANA-FirstAuth-End-Request (PFER)
         PANA-Reauth-Request (PRAR)
         PANA-Termination-Request (PTR)

   *)  PSR that carries a Cookie AVP is not retransmitted.
   **) PSA that does not carry a Cookie AVP is not retransmitted."

(Note: PFER message is introduced for issue 52.)

Regards,
Yoshihiro Ohba

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Mar 2004 01:29:33 +0000 (GMT)

> - PDI is retransmitted whatever information is used as a tie-breaker.
> 
> - As a general retransmission policy, in a request/answer exchange, the
> requester should take the responsibility of retransmission.
> 
> - There is an exception.  If the requester remains stateless after
> sending a request, the responder should take the responsibility of
> retransmission.  This cases occurs only for PSR/PSA exchange, and
> retransmission of PDI and PSA can archieve the responsibility.  The
> presence of the cookie indicates that the requester remains stateless.

If there is no PDI, and PSR is not retransmitted at all, when the single PSR 
is lost, the PANA exchange will hang. 

I understand your point. I guess the problem is, "being stateless" and 
"performing unsolicited PAA discovery" do not mix well.

> 
> > Some other clue could be
> > used to stop one side from retransmitting. For example in my case,
> > receipt of PDI by the PAA could cease the PSR retransmissions on the
> > PAA.
> 
> That is also possible.  Which strategy do you think is better?
> 
> Yoshihiro Ohba

Alper

> > Alper
> > > -
> > > > Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Mar 2004 04:51:20 +0000 (GMT)

> Right.  That is why I used "retransmission of PDI and PSA".

Yes,  but PDI is not always used. In case we are performing "data driven 
PAA discovery", we rely on unsolicited PSR. And if, at the same time, 
we want the PAA to stay stateless, there is a problem. According to
your rule, if PSR is lost, there is no retransmission and hence no progress.
This is a problem with your scheme. Do you agree?

> Yes, When PAA is performing unsolicited PAA discovery, the PAA should
> be stateful, otherwise the PANA exchange will hang if PSR is lost.  

Hence PSR is always retransmitted in unsolicited discovery (we no longer
care of we are trying to be stateless or not). If this is what you are saying too,
we are in agreement.

> On
> the other hand, when PAA is perfomring solicited PAA discovery, it can
> be either stateless or stateful.

Yes.

Alper

> > > > > > >    exchanges except PANA-Auth-Request/Answer. PANA-Auth-
> Request
> > > > > > messages