Subject: Re: [Rserpool] Re: Message channel issues

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Apr 2003 17:36:48 +0200

Dear all,

I'm sorry for commenting so late.

Possibly I was not clear during the phone conference. I do not want to
have a control channel only, so the comparison with ftp is not correct.
The data channel is the 'important' one.

I'm happy with the following:
1. If the transport for the data channel is SCTP, multiplex (using PPID)
    the control channel on the same transport connection.
2. If the transport for the data channel is TCP, multiplex (using
    Phils layer) or not. If not, you do not have a control channel.
3. If the transport layer is UDP, you do not have a control channel.

That is a very simple solution.

Best regards
Michael

On Monday, Mar 17, 2003, at 06:15 Europe/Berlin, Phillip Conrad wrote:

> Some comments:
>
> At 01:05 PM 3/13/2003 -0600, Qiaobing Xie wrote:
>> Randall Stewart wrote:
>> > Maybe the solution is no more than two transports be registered
>> > and they must either be
>> >
>> > 1) A single transport for control and data
>> > 2) A single transport for data only
>> > 3) Two transports one for control, one for data..
>> >
>> > If you select <3> then if EITHER channel does not function
>> > then the PE is considered unreachable..
>>
>> I like this... I'd even go a bit further to take out <3>.
>
> Believe it or not, I'm in agreement with Qiaobing on several points.   
> First, I agree that we can probably live without multiple transport 
> registrations.   Why did we want these in the first place?   For two 
> reasons I think.
>
> (1) We wanted to allow for migration from TCP to SCTP for pool users; 
> i.e. allow some pool users that have not yet adopted SCTP to 
> participate in a pool for service X.   However, this can be handled 
> more simply by maintaining separate pools, with separate pool handles, 
> e.g. X-SCTP and X-TCP.   This preserves the principle that a pool 
> should be made up of equivalent services... this concept should 
> include "equivalent in terms of which transport protocol is used".
>
> (2) We wanted to allow for separate data and control channels on two 
> different protocols.  E.g. control channel over SCTP (or mapped TCP) 
> and data channel over UDP, or protocol XYZ, or whatever.    However, 
> Qiaobing makes a case that we can acheive better simplicity by simply 
> requiring that applications that use a transport other than SCTP or 
> TCP for their data channel do NOT benefit from the extended features 
> that the control channel allows.  I.e., you should either use a 
> multplexed control/data channel, or you shoudl not use a control 
> channel at all.   (Interestingly, this is pretty much exactly what I 
> had in mind when I suggested two "modes"  in the original version of 
> the services draft.    I think perhaps it is time to take a second 
> look at that concept.  Qiaobing doesn't seem to like the terms 
> "failover" vs. "nameservice" mode  for the services you get from a 
> muxed control/data channel, or a data only channel (respectively), but 
> I think that the concepts in the services draft are the right ones.
>
> Let me invite folks to re-read the services draft and make some 
> suggestions: is the problem with the concepts, or only with the 
> terminology?     Can we come up with better terms that "failover" vs. 
> "nameservice" mode?
>
> Thanks,
> Phill
>
> _______________________________________________
> 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: Michael Tuexen <[email-masked]>
Date: Tue, 1 Apr 2003 17:36:48 +0200

Dear all,

Best regards
Michael