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

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

Phil,
see my comments below.
Best regards
Michael
On Monday, Mar 17, 2003, at 20:32 Europe/Berlin, Phillip Conrad wrote:

> 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.
>
> (1) In the service draft, replace "failover mode" vs. "nameservice 
> mode" with "multiplexed data channel" vs. "non multiplexed data 
> channel".
>
OK.
> (2) In the service draft, remove application layer acks from protocol, 
> and write up as use case instead.
>
OK.
> (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?
>
> (4) A Note: when you register for SCTP, you may register multiple IP 
> addresses, but only a single port... i.e, you are only registering a 
> single SCTP endpoint.  This is already reflected in the current > drafts.
>
OK.
>
> 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: Michael Tuexen <[email-masked]>
Date: Tue, 1 Apr 2003 17:35:07 +0200

Phil,
see my comments below.
Best regards
Michael

OK.
OK.
OK.

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Tue, 01 Apr 2003 12:30:31 -0500

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.

>see my comments below.
...
>>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.
...
>>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.)
>>
>>managed by rserpool (and do without the services that would be provided 
>>by a control channel.)

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

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Tue, 01 Apr 2003 12:30:31 -0500

Hi Michael:

...
...

Regards,
Phill

---

From: Qiaobing Xie<[email-masked]>
Date: Tue, 01 Apr 2003 12:21:55 -0600

Hi, Michael,

Welcome back :-)

> > mode" with "multiplexed data channel" vs. "non multiplexed data

Phill and I talked about this a bit more and we both felt that it might
be even better if we use a pair of "non-descriptive" terms, such as
"basic mode" and "enhanced mode". This is because people sometimes tends
to stop reading any further and start to imagining the rest when they
see a "descriptive" term :-) This often causes misunderstanding. 

regards,
-Qiaobing

---

From: Qiaobing Xie<[email-masked]>
Date: Tue, 01 Apr 2003 12:21:55 -0600

Hi, Michael,

Welcome back :-)

regards,
-Qiaobing

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Tue, 01 Apr 2003 16:51:58 -0500

Dear Colleagues,
   Yes, Qiaobing is correct; he and I discussed this and I agree with 
him.   I am inclined to use these terms ("basic mode" vs. "enhanced mode") 
in the next version of the service draft if there is no strong objection 
from the list.

Essentially, "basic mode" would be the mode in which there is no control 
channel (and hence, no business cards, etc.).  In this mode, only a single 
transport endpoint could be registered (by port number) to serve as the 
data channel.   This data channel can use "any" transport 
protocol.  However, the transport protocol used must be the same transport 
protocol for all members of a given pool.)   This is similar to the notion 
that all PEs in a given pool must use the same policy type (see section 4.3 
of ENRP draft).

The "enhanced mode" is the one in which all PEs in a given pool must either 
all use SCTP, _or_ they must all use TCP as the transport protocol.   (Read 
the "_or_"  as "exclusive or").     The SCTP association or TCP connection 
provides a multiplexed data/control channel that allows the enhanced 
services (business cards, etc.) that require the control channel.

This raises an issue: I wonder if we should include language in the ENRP 
draft about the "transport protocol" that is similar to that which already 
exists in the ENRP draft about "policy type"... i.e. that the first PE to 
register with a particular pool handle "x" is the one that determines the 
policy type that all PEs must follow for pool "x".

Regards,

Phill

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Tue, 01 Apr 2003 16:51:58 -0500

Dear Colleagues,

Regards,

Phill

---

From: Qiaobing Xie<[email-masked]>
Date: Tue, 01 Apr 2003 17:11:20 -0600

....
> policy type that all PEs must follow for pool "x".

Hi, Phill,

This is a good point. I agree with you that this needs to be added to
ENRP. And we may need an additional error code to indicate: "sorry, your
reg is rejected due to inconsistent transport type".

regards,
-Qiaobing

---

From: Qiaobing Xie<[email-masked]>
Date: Tue, 01 Apr 2003 17:11:20 -0600

....

Hi, Phill,

regards,
-Qiaobing

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Apr 2003 11:23:55 +0200

Hi Qiaobing,

I have no problem in changing the name. I think we just picked
some names to discuss the items.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Apr 2003 11:23:55 +0200

Hi Qiaobing,

Best regards
Michael