Subject: Re: [Rserpool] Clarification regarding RSerPool support for non-SCTP transports

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Feb 2003 06:20:18 -0600

Ok,

Finally, in a quest to catch up on email (and find what
small simple thing I pledged to do in asap :->)
I respond late...

Comments below...

Qiaobing Xie wrote:
> Tuexen Michael wrote:
> ....
> 
>>>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.
> 
> 
> You must mean "PUs not running SCTP" :-)
> 
> 
>>>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.
> 
> 
> yes
> 
> 
>>>* 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.
> 
> 
> yes
> 
> 
>>>* to require that ENRP messages among PEs must use SCTP only.
>>>
>>
>>I think you mean ENRP messages between NSs. Then it is correct.
> 
> 
> yes
> 
> 
>>>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.
> 
> 
> The above was "decided" about a year ago and _I_ haven't heard any objection so far. 
> 
> 
>>>(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.
>>
> 
> 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?
> 
> 
>>>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.
>>
> 
> 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.
> 
> 
>>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.
> 
> 
> 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.
> 
> 
>>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.
> 
All of the above looks good with one exception...

Using a well-known ASAP port will not work for you.. well it
will work with the first PE but what if I want to run
6 PE's on a box.. maybe of different appliation servers... how
can all 6 (potentially different applications) grap the same
port (Yes I know about REUSE-ADDRESS... but this does
not work with different apps)..

I am thinking it would be better to have two ports in the
registration [control]:[proto-type] [data]:[proto-type]. And
optionally [data] can
be set to 0 indicating the control and the data go on
the same port/protocol.

This would:

a) eliminate sending addresses etc in the control stream (good
    for the ugly devices in the network).
b) Provide a simple way to find out if the PE I am going to
    talk to has a seperate control and data channel.
c) One would also know very easily that I need a SCTP type
    socket as well as a UDP type socket (for example) to talk
    to this app.

My 2 cents...

Now if I could only find some clue as to what simple change to
asap I need to make..

Oh, by the way Phil.. I liked your text for asap on
"best effort" resending.. and I put it in... for the most
part un changed... so at least that will go in the update :>

R

> 
> 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 :-)
> 
> 
>>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.
> 
> 
> Yes, this is a potential issue.
> 
> 
>>I hope that Qiaobing and Peter share this view on the result of the dinner.
>>Any comments from them or others?
> 
> 
> Yes. We need to write it down in detail.
> 
> regards,
> -Qiaobing
> 
> 
>>>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
> 
> _______________________________________________
> rserpool mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rserpool
> 
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Feb 2003 06:20:18 -0600

Ok,

Comments below...

This would:

My 2 cents...

R