Subject: Re: [Rserpool] Data transmission

From: Qiaobing Xie <[email-masked]>
Date: Thu, 26 Jul 2001 16:45:53 -0500

Xingang,

Pls see my comments below...

"Guo, Xingang" wrote:
> 
> Qiaobing,
> 
> A very acute clarification.  Nonetheless, some questions:
> 
> 1. Say if we allow "The __ASAP layer__ of the PU will intercept the SCTP
> SEND.FAILURE Notification and select another PE from the list and re-send
> the data to the __ASAP layer of the new PE.", then we must let _ASAP_ to
> know what to re-send.  And this lead to local _ASAP_ SAVING sent data, and
> remote _ASAP_ generating ACK.  It's unlikely that ASAP can share this
> information from SCTP/TCP/...., nor can it find help from APPL, if the
> failover mean to be transparent.

Strictly speaking how to do this is implementation specific. But in
general this is where the data retrieval function of SCTP API will play
a big role. You may want to take a look at RFC2960 for the "conceptual"
definition of the SEND.FAILURE Notification (which suggests the un-send
data being pushed back to ULP along with the Notification). Or you can
take the SCTP socket API draft as an example (where a socket call can
give you back un-send data). 

> 
> 2. If "the __ASAP layer__ of the PU sets up an association with the __ASAP
> layer__ of the PE and sends data directly to the PE with NO ASAP formatting
> or ANY INTERVENTION..", what's the API to APPL?  Still a SCTP socket?  And
> how can ASAP message such as "DATA ARRIVE" be delivered to APPL?  Through
> the same API? (socket)?

No, it will be totally different from the SCTP API.

The RSERPOOL API to the application, consisting of RSERPOOL
notifications and primitives, is part of the ENRP/ASAP draft. It may not
be complete yet in the current drafts and but eventually will be fully
defined.

-Qiaobing

> --Xingang

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: "Guo, Xingang" <[email-masked]>
Date: Thu, 26 Jul 2001 13:13:20 -0700

Qiaobing,

--Xingang

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 9:29 AM
> To: Jose Luis Jimenez Ramirez ECE/TL/NB ID-000 Tlf.4061
> Cc: [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Rserpool] Data transmission
> 
> 
> Jose,
> 
> The root of confusion here is the careless use of PU and PE 
> terminology
> :-)
> 
> See below...
> 
> "Jose Luis Jimenez Ramirez ECE/TL/NB ID-000 Tlf.4061" wrote:
> > 
> > Hi Randall,
> > 
> > Couldn't be more precise these sentences?:
> > 
> > A. When a PU wants to talk to a PE.. it
> 
> This should read:
> 
> When the __app layer__ of a PU wants to talk to the __app layer__ of a
> PE, it calls the SEND primitive specifying the pool name of 
> the PE. This
> triggers the following:
> 
> >    1) ASAP Asks ENRP where it is (Name Resolution procedure).
> > 
> >    2) Gets a list back of PE's that are registered under the
> >       name... (NAME_RESOLUTION_REPONSE )the list has the IP 
> address/ports.
> > 
> >    3) ASAP layer must select one of the PEs in the 
> Pool(Based on the server
> >       pooling policy)
> > 
> >    4) The PU sets up an association with the PE and sends data
> >       directly to the PE with NO ASAP formatting or ANY 
> INTERVENTION.
> 
> This should read: 
> 
>      4) the __ASAP layer__ of the PU sets up an association with the
> __ASAP layer__ of the PE and sends data directly to the PE 
> with NO ASAP
> formatting or ANY INTERVENTION..
> 
> > 
> > I can understand that once the ASAP layer selects the 
> "best" PE for this PU,
> > the ASAP layer doesn't get involved in the transport of 
> data, but there should be a
> > "control" of this communication between PU<-->PE in the 
> sense that for example a
> > SCTP SEND.FAILURE Notification could happen and a new PE 
> should be selected.
> 
> In such case we will have:
> 
>      5) The __ASAP layer__ of the PU will intercept the SCTP
> SEND.FAILURE Notification and select another PE from the list and
> re-send the data to the __ASAP layer of the new PE. The __app 
> layer__ of
> the PU will normally not be notified about the occurrence of the
> failover.
> 
> And finally for completeness:
> 
>      6) When the __ASAP layer__ of the PE receives the data from the
> __SCTP layer__ of the PE, the __ASAP layer__ will simply generate a
> DATA.ARRIVE notification and pass the data to its __app layer__.
> 
> -Qiaobing
> 
> > 
> > So my question is:
> > When you say:
> > 
> >   "4) The PU sets up an association with the PE and sends data
> >     directly to the PE with NO ASAP formatting or ANY INTERVENTION."
> > 
> > Do you mean that the PU (i.e ASAP User) sets up an 
> association directly to the PE:
> > 
> > +-------+            +----+----+
> > + PU    +            +   PE    +
> > +-----  + SCTP assoc +    +----+
> > |ASAP|  |<---------->|    |ASAP|
> > +-------+            +----+----+
> > | SCTP  |            |  SCTP   |
> > +-------+            +---------+
> > |  IP   |            |   IP    |
> > +-------+            +---------+
> > 
> > 
> > Shouldn't  be this assoc established by ASAP, and then ASAP 
> by using a
> > "ASAP UserData message" (not defined yet), send this User 
> data to the PE, without
> > processing the content?
> > +-------+            +----+----+
> > + PU    +            +   PE    +
> > +-------+ SCTP assoc +---------+
> > | ASAP  |<---------->|  ASAP   |
> > +-------+            +----+----+
> > | SCTP  |            |  SCTP   |
> > +-------+            +---------+
> > |  IP   |            |   IP    |
> > +-------+            +---------+
> > 
> > Maybe the solution is something like this:
> > ASAP bypass UserData (No ASAP UserData message should be defined),
> > +-------+            +----+----+
> > + PU    +            +   PE    +
> > +-------+ SCTP assoc +    +----+
> > | ASAP  |<---------->|    |ASAP|
> > +-------+            +----+----+
> > | SCTP  |            |  SCTP   |
> > +-------+            +---------+
> > |  IP   |            |   IP    |
> > +-------+            +---------+
> > 
> > Can anybody clarify this.
> > I'm in a mess :-o
> > 
> >                    - -
> > Regards            º º
> > Jose      --oOOo---()--oOOo--
> >

---

From: Miguel Angel Nieto Jimenez <[email-masked]>
Date: Fri, 27 Jul 2001 10:12:03 +0200

Hi,

   Please see my comments embedded

> give you back un-send data).

I think that once the association is established, ASAP work has
finished. If it receives a SEND.FAILURE Notification, it should
notify this to its user and provide it another PE handle. Then the
user can decide if wants to go on the communication or not with
the second PE. ASAP can't switch directly to the second PE because
the state of the communication is not known, this is application
specific.

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Jul 2001 12:47:29 -0500

Miguel Angel Nieto Jimenez wrote:
...
> finished. 

Not at all. The architectural principle of RSERPOOL is to hide the
transport details from the user (i.e., whatever is above RSERPOOL). ASAP
is always there as long as the _session_ exists. Normally, the user of
RSERPOOL only manages _session_ and does not _need_ to know anything
about the underneath transport associations (such as which one is being
used, which one has failed, how many still in operation, etc.). This is
the whole idea of RSERPOOL.

> If it receives a SEND.FAILURE Notification, it should

You are describing an optional mode of RSERPOOL, that is, for some
reason the user of RSERPOOL _chooses_ not to have transparent failover
and instead wants to handle the failover by itself. 

In our implementation, this is controlled by a SEND primitive flag and
the default behavior is (you guess) to let the RSERPOOL handle failover
:-)

-Qiaobing