Subject: Re: Requirement Clarification ....

From: Tuexen Michael <[email-masked]>
Date: Tue, 23 Jan 2001 14:44:00 +0100

Dear all,
See my comments below.
Best regards
Michael

Michael Tüxen     Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SEN 51  E-mail: [email-masked]

> -----Original Message-----
> From: Randall R. Stewart [SMTP:[email-masked]]
> Sent: Tuesday, January 23, 2001 2:30 PM
> To:   [email-masked]
> Subject:      Re: Requirement Clarification ....
> 
> Ram:
> 
> I think Qiaobing got all of these issues :)
> 
> I think the big thing to remember here is that
> the document you are looking at is about to have
> a major set of clearifications put into it.. This
> will (I hope) make things a little clearer for all..
> 
> Hopefully all of your items will be addressed in
> the next revision.
        [Tuexen Michael]  They will be addressed. 
> R
> 
> 
> Qiaobing Xie wrote:
> >
> > Ram,
> >
> > Sorry for not responding to you questions earlier... There was an
> > off-line thread asking for some clarification to the document similar to
> > yours and I guess some of our co-authors (including myself) might have
> > thought they were answering the same list of questions without realizing
> > the answers were not cc'ed to the list..
> >
> > regards,
> > -Qiaobing
> >
> > Ram Gopal wrote:
> > >
> > > Hello all,
> > >
> > > I have some problem in understanding the requirement document , can u
> > > clarify the following items,
> > > please refer to  requirements documents.
> > >
> > > Refer Section 1.2 Terminology:
> > > ------------------------------
> > > Pool Elements: Both client or  Server providing services....
> > >
> > > I think my understanding is only server provides service and no one intiate
> > > a call with client.
> >
> > The wording used here may not be completely accurate and need to be
> > polished, as you have noted, but the idea is that a PE can also behave
> > at some point of time as a client requesting services from servers
> > outside the pool. The important thing is that rserpool is meant to be a
> > peer-to-peer solution.
> >
> > > Refer Section 2.2 .  Rserpool protocol overview
> > > ------------------------------------------------
> > > In the ending of first paragraph there is some thing about local host and
> > > remote host.
> > > What is local and remote host ?
> >
> > "local host" here means the host on which the ENRP server itself resides
> > and "remote host" = any other hosts...
> >
> > > Refer Figure 2.1
> > > ----------------
> > > What is the difference between PU and "Other Clients" ... is the PU client
> > > for PE....?
> >
> > "Other clients" are those who do not support Rserpool, e.g., legacy
> > applications..
> >
> > >
> > > Refer Section 7:Security aspects
> > > --------------------------------
> > > It should be possible that the name resolution is encrypted.
> > >
> > > What exactly this mean ?
> >
> > Details need to be worked out by the WG, but the idea is to prevent your
> > name translation query/response from being picked up by unauthorized
> > third party tapping on your network. Sending them in plain text
> > certainly won't meet this goal.
> >
> > >
> > > Refer Section 7: Security aspects
> > > ---------------------------------
> > > It should be possible to encrypt the communication between the
> > > client and the host?
> > >
> > > Does host here refers to a pool element ?
> >
> > Good point. This should be clarified as "... the communication between a
> > PU and a PE"
> >
> > >
> > > Regards
> > > Ramg
> 
> --
> Randall R. Stewart
> [email-masked] or [email-masked]
> 815-342-5222 (cell) 815-477-2127 (work)

---

From: sohrab modi <[email-masked]>
Date: Tue, 23 Jan 2001 10:24:25 -0800

> > > outside the pool. The important thing is that rserpool is meant to be a
This is completely correct. just one other related nit in the
requirements document that I did not see...

In section 2.3 (of some version of the document that I have), I did not
see any mechanisms by which PE's could talk to other PE's?  Would their
be a reason to do this? If they could I would assume that they would use
ASAP?  Has this been purposefully left out?

Another question that I have is related to the definition of a
service/services, in the creation of a pool.  Eventually such a
definition will translate into a low level network centric definition
like <Family type (Ipv4/IPv6 for now), protocol (TCP/UDP/...) IP
address, port>.
Server pools are containers for services and as such clients get
redirected to elements of the pool by the enrp server. This would
satisfy a classes of services like telnet or a basic http service.
However there are a certain class of services that may require some
sense of affinity between them.  As much as you may wish to abstract the
application layer out, I feel that in this context we should at least
consider the consequences.

consider the example where http is configured for Pool 1 and secure http
is configured in pool 2.

Clearly this could create complications for things like reconciling
shopping baskets (http) to their credit cards (on secure http).  Now
simply having secure http  also be part of pool 1 is still insufficient
because the client desiring affinity may still be directed to another
element of the pool (PE) and you still will not be able to reconcile
your shopping.

There are multiple ways of solving this problem, as well as numerous
examples of services requiring affinity  Should we be attempting to
solve this problem?  Interestingly enough, if we take load balancing as
a consideration for this draft, then supporting client affinity while
attempting to solve the load balancing problem will certainly make for
an interesting problem.

Thanks

Sohrab Modi

---

From: sohrab modi <[email-masked]>
Date: Tue, 23 Jan 2001 10:49:16 -0800

> > > > at some point of time as a client requesting services from servers
A clarification to my earlier mail ...

> see any mechanisms by which PE's could talk to other PE's?

This should be PE's talk to other PE's "in the same pool".

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 23 Jan 2001 14:53:15 -0600

Sohrab:

First thing comes to my mind for intra-pool PE-to-PE communications is
for state information sharing when the service provided by the pool to
its PUs is a stateful service. A-SAP can certainly be used for this
communication (e.g., in the current A-SAP draft, there is a "send to all
my peers in the pool" operation mode that is exactly created for this
purpose). However, this intra-pool communication should not, nor needs
to be, restricted to A-SAP; for example, for people who are looking for
extremely fast performance at any cost, they should be allowed to use
special hardware (mirrored memories, etc.) to carry out this intra-pool
communication, while for those who are cost conscious, a shared file
system may be good enough.

My opinion is: since so far the consensus seems to be that state sharing
mechanism is out of the scope, the communication methods for sharing
state info should not be covered by the requirements.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 23 Jan 2001 15:19:16 -0600

...snip...
> element of the pool (PE) and you still will not be able to reconcile

Locating services and how to form service affinities are certainly
interesting problems to solve. But I'd think that Rserpool is primarily
focused on how to achieve transparent failover from one server (PE) to
another *functionally identical* server in the same pool, i.e, achieving
application robustness by pooling is the primary goal of Rserpool. Load
balancing is just an extension to this primary goal - one would always
like to failover to the most lightly loaded alternative if more than one
exist.

Maybe at a later stage we will find that it is not too much for the WG
to address additional goals such as service affinities, but I'd suggest
that we focus on the robustness issue first.

regards,
-Qiaobing

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 25 Jan 2001 08:51:01 -0600

> that we focus on the robustness issue first.
Agreed, lets get the basic's down first but possibly keep our
minds open to adding the service affininities as we proceed forward.

If we can leave openings for later or for that matter find a way to add
it simply, then it would be worth doing.

R

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 25 Jan 2001 08:47:38 -0600

> ASAP?  Has this been purposefully left out?
One of the things we have (or should be there and we need to add
if it is not in ASAP) in ASAP is the ability to send to all
of my peer PE's. It was called the SEND_TO_ALL option. This should
probably be reflected in the requirments. This is a "hook" that can
help you build a primitive shared state mechanism... i.e. you send
to all of your peers when a state change commit happens. Obviously this
does NOT scale well for large server pools but it can be useful. Q and
I used this to build a set of BB servers that each maintained shared
memory. Then multiple PE's could use the shared memory and tickle
the BB server to distribute the state when a "push" was done. This
somewhat minimized the problem of the scalablility ... in at least
having multiple servers on one machine collapsing (as far as the
state sharing) into one set of communications...

Anyway this is a GOOD point and shoud be in here...

Also there are other things that communicating ASAP entries may need
to say to each other... i.e. If I am in one pool and you another I will
want to pass my name (hidden to the app) so you too can use a handle
to get to me... I used to call this a business card that you pass
to the peer at first communications.. Its not in the ASAP draft but
should be...

> attempting to solve the load balancing problem will certainly make for

Yes, I agree... it would be nice to have a way to look up a name and
get some sort of hierachy back... here is your PE list, and by the
way releated to each server is this other server... hmm tough problem
but one worth examining...

R

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 25 Jan 2001 08:49:25 -0600

> state info should not be covered by the requirements.

Hmm this is a good point, maybe not in the requirments but I certianly
think we should put hooks in for primitive state sharing... i.e.
communication
with ALL in a pool. We may need some limit on how many "all's" you can
send to at once though..

R