Subject: Fwd: [Rserpool] Directions for next version of service draft

From: Michael Tüxen <[email-masked]>
Date: Wed, 2 Apr 2003 11:21:32 +0200

Just forgot the mailing list...

Begin forwarded message:

> From: Michael Tuexen <[email-masked]>
> Date: Wed Apr 2, 2003  11:20:45 Europe/Berlin
> To: "Phillip T. Conrad" <[email-masked]>
> Subject: Re: [Rserpool] Directions for next version of service draft
>
> Hi Phil,
>
> I agree with you and prefer also that solution. I just was not sure
> if this is the common understanding.
>
> Best regards
> Michael
>
> On Tuesday, Apr 1, 2003, at 19:30 Europe/Berlin, Phillip T. Conrad 
> wrote:
>
>> Hi Michael:
>>   Thanks for responding to request for "rough consensus" in my 
>> previous note on several points related to the next version of the 
>> service draft.    In your reply, you indicated acceptance of the 
>> suggested directions, with just one question: I've included the 
>> context for that question, and answered it below.
>>
>> At 05:35 PM 4/1/2003 +0200, Michael Tuexen wrote (in part):
>>> Phil,
>>> see my comments below.
>> ...
>>>> Here are some suggested directions for RSerPool:
>>>>
>>>> To the working group: do we have rough consensus on these points?  
>>>> I and others (Peter, Randy, Qiaobing et al)  will ask for rough 
>>>> consensus on these points in the working group meeting later today 
>>>> in San Francisco... and for the sake of those that are NOT in the 
>>>> meeting today, please consider this email as your opportunity to 
>>>> express support, dissent, or to ask for further clarification on 
>>>> the points below.
>> ...
>>>> (3)  In general: No multiple transport registrations: you either
>>>>
>>>> (a) register the transport address of either an SCTP or TCP (but 
>>>> not both) multiplexed control and data over a single transport 
>>>> association/connection.  (Note: you _can_ register both, but if you 
>>>> do so, they should be in different pools, preserving the principle 
>>>> that all PE's in a pool should be functionally equivalent, 
>>>> including all using the same transport protocol to provide >>>> service.)
>>>>
>>>> (b) you register the transport address of a data channel only, not 
>>>> managed by rserpool (and do without the services that would be 
>>>> provided by a control channel.)
>>> Is this the same for all PE in a Pool?
>>
>> To my understanding, yes: the notion is that all PEs in a given pool 
>> should behave the same way.   That is one of the architectural 
>> principles we are trying to emphasize as we move forward, for the 
>> sake of simplicity.  So, I think we should emphasize in the various 
>> drafts that for a given pool, all PEs either behave according to the 
>> rules of (a) above, or all PEs behave according the rules of (b).
>>
>> What we gain by this direction is simplicity.   We lose some 
>> flexibility (in particular, we lose the ability to support some of 
>> the scenarios below), but I think the sense of the group was that 
>> none of these things are terribly important; i.e. we do not have 
>> application scenarios that require these particular capabilties.    
>> Here are some of the capabilities we give up:
>>
>> (1) the flexibility to failing over among a group of PEs, where some 
>> have a control channel, and others don't.
>> (2) the flexibility to have a data channel on one transport address 
>> and protocol, and a control channel on a different transport address 
>> and perhaps a different transport protocol.
>>
>> I hope this explanation is helpful, and I invite comments or 
>> questions from anyone on the list.
>>
>> Regards,
>> Phill
>>
>>
>

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

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 2 Apr 2003 11:21:32 +0200