Subject: RE: [Rserpool] Clarification regarding RSerPool support for non-S CTP transports

From: Tuexen Michael <[email-masked]>
Date: Tue, 26 Nov 2002 17:16:08 +0100

Dear all,

see my comments below.

Best regards
Michael

Michael Tuexen   Tel.:   +49 89 722 47210
Siemens AG       Fax:    +49 89 722 48212
ICN CP SE C 7    e-mail: [email-masked]

> -----Original Message-----
> From: Phillip Conrad [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 6:10 AM
> To: Rserpool list
> Subject: [Rserpool] Clarification regarding RSerPool support for
> non-SCTP transports
> 
> 
> I would like to ask the working group for clarification of 
> some points regarding support for transports other than SCTP.
> 
> As I understood it, a key motivator was to allow for the 
> possibility of PUs that supported TCP but not SCTP.     The 
> example of such a requirement was some device for which an 
> SCTP implementation is not yet available; perhaps some 
> particular model of cell phone, PDA, or whatnot.
To be more precise:
- Support of PUs not running TCP. This means that we need
  to provide a method for PU <-> NS communication based on
  TCP. The data channel between PU <-> PE can be everything.
  The control channel between PU <-> PE can be TCP.  
> 
> As a result, I think we reached something like "rough 
> consensus" on the following direction:
> 
> * to provide a way to send ASAP messages 
>   between a PU and a PE over either SCTP or TCP
This means the control channel can be SCTP or TCP based.
> 
> * to provide a way to send ASAP message between 
>   an PU and a Name Server over either SCTP or TCP
Correct. We do NOT need a mapping here, since all ASAP
messages are TLV.
> 
> * to require that ENRP messages among PEs must use SCTP only.
> 
I think you mean ENRP messages between NSs. Then it is correct.
> 
> Three questions: 
> 
> (1) Is that the correct sense of the working group?  Is there 
> any significant dissent from that point of view?   If so, 
> please say so.
> 
> 
I provided my view to the above questions.

> (2) There might be one additional goal: 
> 
> * to specify how RSerPool is used when the application 
> prefers to use RSerPool only for server selection (i.e. to 
> resolve a pool handle to a transport address) and to handle 
> the sending/receiving of data outside the RSerPool framework. 
>    The application also has the responsibility to detect and 
> report server failures in this case.
> 
> Is there working group consensus about this goal... yes or 
> no?  If any doubts whether this should be a goal, please speak up.
> 
> I know there is still not full working group consensus that 
> the "mapping" approach taken in the current drafts is the 
> right way to go (in fact, I am aware of some particular 
> doubts).  But before we debate the "how", I want to be sure 
> we at least have rough consensus on what the goal(s) is/are.

I think we agree on the NS <-> NS communication (SCTP only),
PU <-> NS communication (TCP or SCTP communication, no 'mapping').

The open point was the PE <-> PU communication. We have the notion
of control and data channel. To be more precise type one and type two
data channel.

At Thursday evening (Peter, Qiaobing and myself having dinner) we started
(again) the discussion how this will work. The results of the discussion are
- UDP based data channels with a control channel should be supported.
- The way of using the same transport connection for data and control channel
  is not sufficient because of the support of UDP.
- Old applications running UDP and/or TCP should be supported without
  modifying their protocol.

So we came up with the following suggestion:
- If SCTP is used mulitplex the data and control channel based on the PPID.
- If TCP is used and ASAP send calls you can use the mapping document to
  multiplex the data and control channel on one TCP connection.
- If TCP, UDP (or DCP) is used for the data channel used a seperate
  SCTP or TCP based control channel to a port at the PE. This port number
  could be a well known ASAP port or be part of the name resolution message.
  This solution works for that type of channel were the send call is not
  a ASAP send-call. You can call that support of 'old' applications.

How is the information provided which control channel belongs to which
data channel: The first message on the control channel is send by the PU 
and contains the information about protocol, local IP address, remote IP address,
local port number, remote port number. 

This would be an easy solution, but we transport IP addresses in the payload
making the RSerPool deployment hard in networks with NATs.

I hope that Qiaobing and Peter share this view on the result of the dinner.
Any comments from them or others? 

> 
> Thanks,
> Phill Conrad
> 
> _______________________________________________
> rserpool mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rserpool
> 
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 26 Nov 2002 18:23:36 -0600

Tuexen Michael wrote:
....
>   The control channel between PU <-> PE can be TCP.

You must mean "PUs not running SCTP" :-)

> This means the control channel can be SCTP or TCP based.

yes

> Correct. We do NOT need a mapping here, since all ASAP

yes

> I think you mean ENRP messages between NSs. Then it is correct.

yes

> I provided my view to the above questions.

The above was "decided" about a year ago and _I_ haven't heard any objection so far. 

> > no?  If any doubts whether this should be a goal, please speak up.

This goal is about using a subset of what available in RSERPOOL and thus is achievable by
default (i.e., the app can always choose only to use a subset of features built in ASAP).
Or, are you asking group consensus on prohibiting this particular way of using RSERPOOL?

> > we at least have rough consensus on what the goal(s) is/are.

Mapping is not our goal. Mapping is part of "how" :-)  I think we have consensus to
support the PU <-> PE control messages already but we don't have consensus on whether
"mapping" is the best way to do it.

>   modifying their protocol.

Considering 3GPP, if they are told that they have to change their GTP in order to use
RSERPOOL among their nodes, the whole industry will by-pass RSERPOOL in a heartbeat.

>   a ASAP send-call. You can call that support of 'old' applications.

Yes. This is the basic idea. But we probably should not distinguish mapping from
non-mapping based on whether the app uses an ASAP send-call or not because that is not
fundamental. For example, an implementation may build a convenient ASAP "socket" that
manages two TCP sockets underneath - one for un-alternated/un-mapped use data transmission
and the other for sending control messages. This way, the ASAP can perform failover etc.
by moving the data transmission from one TCP socket to another, while the app gets the
convenience of only needing to deal with a single ASAP "socket" to send data. And there is
no mapping on the data channel. For one, I most likely will build my implementation this
way. So if you think I shouldn't do that, please tell me why now :-)

> making the RSerPool deployment hard in networks with NATs.

Yes, this is a potential issue.

> Any comments from them or others?

Yes. We need to write it down in detail.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 26 Nov 2002 18:23:36 -0600

Tuexen Michael wrote:
....

yes

yes

yes

regards,
-Qiaobing