Maureen.Stillman | 1 Jul 15:35 2006
Picon

Topics for the agenda

Please send any topics for the Montreal agenda.  We have a 2 hour slot.

Thanks.

-- Maureen
Maureen Stillman
Nokia Enterprise Solutions
Acting Director SMC Systems Architecture

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Michael Tuexen | 1 Jul 20:42 2006
Picon

Re: Topics for the agenda

We could talk about the RSerPool API... Randy, Peter and myself had
some discussions.

I could also present the rsplib, developed by Thomas Dreibholz.

Best regards
Michael

On Jul 1, 2006, at 3:35 PM, <Maureen.Stillman <at> nokia.com> wrote:

> Please send any topics for the Montreal agenda.  We have a 2 hour  
> slot.
>
> Thanks.
>
> -- Maureen 
> Maureen Stillman
> Nokia Enterprise Solutions
> Acting Director SMC Systems Architecture
>
> _______________________________________________
> rserpool mailing list
> rserpool <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rserpool
Randall Stewart | 2 Jul 13:45 2006
Picon

Re: Topics for the agenda

Maureen/Michael/All:

I will be glad to talk about my fun experience implementing
rserpool err.. at least asap.. I am not done yet
but have made some comments to the list (so far) and can
discuss some of the things I have seen... I still don't
know if I will get implemented enough to participate in the
inter-op or not.. my time is being eatten up by a lot of
other things (vacation until the IETF for one thing ;-D)

Anyway... I could talk for about 10min or so :-D

R

Michael Tuexen wrote:
> We could talk about the RSerPool API... Randy, Peter and myself had
> some discussions.
> 
> I could also present the rsplib, developed by Thomas Dreibholz.
> 
> 
> Best regards
> Michael
> 
> On Jul 1, 2006, at 3:35 PM, <Maureen.Stillman <at> nokia.com> wrote:
> 
>> Please send any topics for the Montreal agenda.  We have a 2 hour  slot.
>>
>> Thanks.
>>
>> -- Maureen Maureen Stillman
>> Nokia Enterprise Solutions
>> Acting Director SMC Systems Architecture
>>
>> _______________________________________________
>> rserpool mailing list
>> rserpool <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/rserpool
> 
> 
> 
> _______________________________________________
> rserpool mailing list
> rserpool <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rserpool
> 
> 

--

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)
Maureen.Stillman | 5 Jul 17:10 2006
Picon

Draft agenda for IETF #66

Introduction
Lyndon Ong, Maureen Stillman, co-chairs

Discussion of ASAP implementation
draft-ietf-rserpool-asap-13
Randy Stewart

Comments from Genart reviewers
draft-ietf-rserpool-asap-13
draft-ietf-rserpool-enrp-13
draft-ietf-rserpool-common-param-10
Randy Stewart

Rserpool APIs
Michael Tuexen

Rsplib
Michael Tuexen

Next steps, Closing remarks
Lyndon Ong, Maureen Stillman, co-chairs

This has been posted.  Please let me know if you have any comments.

-- Maureen
Maureen Stillman
Nokia Enterprise Solutions
Acting Director SMC Systems Architecture

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Ong, Lyndon | 12 Jul 19:13 2006

FW: [Fwd: Re: Review: draft-ietf-rserpool-arch-11.txt] Baker comments

Full text of Randy's response

L. Ong

Picon
From: Randall Stewart <rrs <at> cisco.com>
Subject: Re: Review: draft-ietf-rserpool-arch-11.txt
Date: 2006-07-10 12:54:48 GMT
Fred
> 
> I still don't have a definition of a "business card". Is that a .vcf  
> file? If so, I have no idea how it guides a user failover; the  business 
> cards I am aware of are small files that contain a human  being's 
> contact details. See attached.
> 
> 
> 

Business card MAY have been a bad choice in names... its a
last will and testament a server tells the ASAP layer of the client
to use for failovers...

One thing about this document.. Michael and I have been talking this
morning.... It has:

a) Went through several terminology changes (we argued quite
    a bit over pool name/ pool handle.. and all the other
    terms.. many of them still confuse me :-D)

b) It went through several iterations of changing passive voices..

c) And seems to me to need much more clearification.. I know when
    I was asked to dig into it ... I really only added the first
    few paragraphs in the Intro section... having been burned out
    on the terminology arguments a few years ago... :-0

I still need to go finish my responses to you.. my landing cut short...

But without having read the rest of your email (I was replying and
reading in real time)... does the basic concepts of what we are
trying to do.. however poorly they were presented to you.. get
through and make sense to you???  We definetly need to fix the
wording... and I think Michael said he can get the MS doc grammer
stuff to run on his mac.. maybe through emulation :-0... hopefully
we can turn him loose to fix it :-D

R

--

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Ong, Lyndon | 12 Jul 19:14 2006

FW: [Fwd: Re: Review: draft-ietf-rserpool-arch-11.txt] Baker comments

Third response from Randy.

L. Ong

Picon
From: Randall Stewart <rrs <at> cisco.com>
Subject: Re: Review: draft-ietf-rserpool-arch-11.txt
Date: 2006-07-10 14:00:52 GMT
Fred:

A better example might be IP-Fix or say BGP..

I have a pool of IP-Fix collectors.. and some
number of routers that want to be PU's... aka
the client that sends data to the collectors.

Or.. I have a pool of BGP Servers that also act
as clients .. you point your two pools at each
other.. some at ISP-1 and the other at ISP-2..

Now your BGP servers talk over rserpool to each
other in a peer-2-peer form.. if one of them
fails.. it fails over to another WITHOUT withdrawing
routes... necessarily..

Hmm.. Maybe I can construct a more sensical example
with these :-D

R

--

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Ong, Lyndon | 12 Jul 19:15 2006

FW: [Fwd: Re: Review: draft-ietf-rserpool-arch-11.txt] Baker comments

Final response from Randy.

L. Ong

Picon
From: Randall Stewart <rrs <at> cisco.com>
Subject: Re: Review: draft-ietf-rserpool-arch-11.txt
Date: 2006-07-11 19:07:57 GMT
Ok, continuing where I left off while hearing
crys of anguish over TURN/STUN and other fun :-D

Fred Baker wrote:
> 
> Dumb question. Does the pool handle identify the pool of servers, or  
> does it identify a server in the pool? It seems to me that there are  
> uses for both forms of identifiers.
> 
>>    These pool handles are not valid in the whole internet but only in
>>    smaller domains, called the operational scope.
> 
> 
> What if the operational scope is the whole Internet?

I answered the above...
> 
> It seems to me that "the whole internet" is a network layer  
> description, while the operational scope is an application layer  
> description. As such - and maybe it's just me - the above doesn't  make 
> a lot of sense.

Hmm the idea is to somehow scope the rserpool area that you
have running... and yes I guess it is kind of an application
sense... I don't what to have ONE RSERPOOL running over the
whole internet.... some super DNS.. thats not the idea..

Instead I will run, say at my home, a small area that offers
services inside my home.. thats really a bad example..

Say I am building a set of netflow collectors. I set up
a small pool in maybe the span of a city that has all my
collectors in one pool. All of my cisco routers know how
to find the operational scope.. they want

"netflow collector"

They then talk to the ENRP servers that are running in
this scope.. and setup and start sending their peg
counts to one of the PE's that registered with the
"netflow collector" name.. If that one fails.. they
fail over and send the pegs to another one...

Do I want all of my "netflow collector" in the ISP to
be in one scope.. maybe (I have seen this stuff work
inbetween Dallas, TX and a Japan office).. but maybe
not. The administrator will setup the domain that this
thing scopes in :-D

> 
> Example: www.microsoft.com, if you look it up using nslookup, appears  
> to be a service that is offered through a distributed redirection  
> service to a variety of individual servers. I have no idea how many  
> servers are involved or where they are located, but I get the idea  that 
> there is some DNS server that resolves that name with some  knowledge of 
> the source address, yielding something akin to what  Akamai does with 
> names, and without resorting to anycast routing  (which IMHO would be a 
> superior solution, but I digress). Now, the  operational scope of the 
> service is "anyone who might access  www.microsoft.com", which is far 
> too many end systems - it  effectively IS the whole Internet. The pool 
> handle in this case would  seem to be implemented at the network layer, 
> and is the address  returned for the instance of that service that a 
> given user will access.
> 
> So help me out here. What in the world is this "operational scope"?

Hmmm I see  your point.. but I (microsoft) do not want to join
the whole internet so that anyone can add "their server" to
the "www.microsoft.com" pool. Instead I will have a scope
that is bounded inside the MS network. Yes the user (PU) will
have to attach into that scope... to find "www.microsoft.com" and
thus the proper server...

The pool may be accessible from anywhere on the internet .. but
the set of ENRP servers is maintaining a small subset of names
in its 'scope'.. which is smaller than the big-bad internet...
even though each scope is accessible to folks on the internet...

I realize the concept is not clear, but I am not sure what
the terminology should actually be.. operational scope is
probably a bad choice... its almost an administrative domain...

> 
>>    In each operational scope there must be at least one ENRP server.
>>    All ENRP servers within the operational scope have knowledge of all
>>    server pools within the operational scope.
> 
> 
> so, coming back to www.microsoft.com, let's suppose that it is  
> implemented as some number of groups of servers, each group of which  is 
> co-located  in one of Microsoft's favorite service providers. You  are 
> presuming that there is at least one redundancy server in the  service, 
> and perhaps one or more in each such group of servers. So  you are 
> calling the groups of servers in a given colo location a  pool, and the 
> entire thing a service? Is that right?

Yes I think so... you have one or more ENRP servers... inside some
administrative bounds (or operational scope) that MS chooses to
draw.. it may be just Redmond, or it may be Redmond+SantaClara or ??

anyway.. the servers in that pool, processes on boxes, open up
an rsp_socket() and register "www.microsoft.com". They all hopefully
offer the same service, if not, its an administrative error. So
when I contact a registered www.microsoft.com I get some service
from it.. the same service whichever "pool element handle" (my
how I hate that term).. I may access :-D

> 
>>    Pool element: A server entity having registered to a pool.
> 
> 
> This is a nice architectural term, I suppose. It doesn't help the  
> reader much, though. The pool element is an instance of an  application 
> (in a virtual server, there might be many such running on  the same 
> physical hardware) that has registered with a pool server. 
Yep, if I start 20 copies of the process foo, which all
register has "randall".. they all are on the same machine and
provide the "randall" service... Hopefully I would start
them on multiple boxes too :-D

  Instead of
> focusing on the hardware it runs on (the server), could  you call it an 
> "application instance" or an "instance of an  application", and the pool 
> itself a pool of application instances?

Amen.. we needed you to be present in the naming wars of the past..

I like the term application instance and "pool of application
instances". Much more clear to me and hey, even though its not
my previous terms .. I don't have to have a mental image and
translate between the two :-D

> 
> I'm a humble engineer. I just make stuff work. When I define terms, I  
> usually try to do so in a manner that will help me point to objects  in 
> pictures. So far, the terminology in this document has me  completely 
> lost. If you were to explain it in English...

I cannot disagree.. since I never agreed with the terminology myself :-D

> 
>> 2.1.2.  ENRP Servers
>>
>>    The second class of entities in the RSerPool architecture is the
>>    class of ENRP servers.  ENRP servers are designed to provide a  fully
>>    distributed fault-tolerant real-time translation service that  maps a
>>    pool handle to set of transport addresses pointing to a specific
>>    group of networked communication endpoints registered under that  pool
>>    handle.
> 

boy is the above not a confusing set of gibberish :-D

> 
> what is a "transport address"?

A transport address is a open socket that some application is
listening on for messages :-D Usually a IPaddress+Port+Protocol type.

> 
> I can tell you what a TSAP is, or a TCEPID, if that is what you're  
> getting at. A TSAP is the name a transport client uses to identify  its 
> connection to the transport, and a TCEPID is the name used to  identify 
> the transport in a a remote system when talking to the  network layer 
> and asking for connectivity (it translates to an NSAP  and a 
> multiplexing ID). In the IP architecture we don't talk much  about those 
> concepts, though - that's OSI. We generally talk about  the network 
> layer having addresses and the transport layer having  ports, and when 
> talking to a remote application we talk about the  network address and 
> transport port number that the application is using.

The combination of an IP address + Port is a transport address.. this
is a term we put into SCTP.. I think... and has echoed into these
documents... I still don't like the 2.1.12 paragraph :-D

> 
> If that is what you're calling a "transport address", you'd best  define 
> the term. The text in this section about the destination  address, 
> protocol, and port might be a good starting point.

Hmm I am surprised or maybe not.. that its not defined in the document
:-0

> 
> Or if you really mean an internet address, say so. We have enough  
> confusion in the IETF with bellheads that call the physical layer the  
> "transport". We don't need people misidentifying the internet  sublayer 
> of the network layer as the "transport" too. SCTP and TCP  are 
> transports - that's what the "T" stands for.

Yep..

> 
>> 2.1.3.  Pool Users
>>
>>    A third class of entities in the architecture is the Pool User (PU)
>>    class, consisting of the clients being served by the PEs of a  server
>>    pool.
> 
> 
> What on God's Green Earth is a "user" in this situation? Is it a  
> person? An application? What?

To me its a client application that wants to use the pool aka
a client that wants to gain access to an application instance
to service a request...

> 
>> 2.2.2.  Aggregate Server Access Protocol
>>
>>    The PU wanting service from the pool uses the Aggregate Server  Access
>>    Protocol (ASAP) to access members of the pool.
> 
> 
> OK. So I'm a pool user (kid in a bathing suit, I think). 
The vision in my mind is not pretty :-D

I want to  use
> your Rserpool thing to, I dunno, open a BEEP connection to an  
> application in some other system. That means I'm going to open an  SCTP 
> connection (yes, Marshall never wrote down BEEP/SCTP, but he  should 
> have)

He did but the document feel by the wayside due to my not having
the cycles to make sure it became an RFC.. I could probably dig
up an old copy if you wanted :-D

  to a given Internet address and transport port number,  which will
> get me to that application. Do I have to also open an ASAP  connection 
> to a server to tell me which one to address? I thought I  got that from 
> DNS?

In theory if you have a configured ENRP server.. you talk to
that..

So lets say I start processes on

lakerest.net, bsd.lakerest.net and bsd2.lakerest.net

They are all the same "beep" service registered as the name
"randall". There is also an ENRP server running on lakerest.net
and bsd.lakerest.net.

So, I the user, figure out where lakerest.net is. (70.155.160.98)
Now, the PU connects to 70.155.160.98 port ENRP via SCTP.
It now does a query

----Tell me("randall")----->

<---gets back a randall's are at
      70.155.160.98:port2222 (sctp)
      70.155.160.99:port3333 (sctp)
      and
      70.155.160.100:port4444(sctp)

Now, in this are also a load balancing policy
and some other goodies.. no big deal..

ASAP in the client/user (PU) then selects one based
on the algorithm.. lets say 70.155.160.100:port4444
since 4 is my lucky number :-D

It then sends a INIT---> 70.155.160.100:port4444
and starts send the application (BEEP) request.

It may get back right away from the server

<-------ASAP(DWL, COOKIE)-----

DWL = Death Wish List (the failover order listing 2222 then 3333)
and
COOKIE = which is some form of state cookie that on failover
          would be presented to the new "randall" spoken to.

Now the application sends/recvs its messages...

Note I have changed BC (business card) to DWL... since
I like this better.. even though its politically less correct :-D

> 
> Or is the pool user someone else?If so, who?
> 
>>    o  The PE can send a business card
>>
>>    o  The PE can send cookies
> 
> 
> these are defined terms, right? No, they are not defined in 2.3; 2.3  
> merely says that they can be shipped around.
> 
> To me a business card is a small piece of paper, and a cookie is as  
> defined in Betty Crocker...

In the above instance the DWL(BC) is a listing of
who to failover to next. Its a last/will and testament
if you will..

The Cookie is some form of state if the application instance
dies that should be presented to the next "randall" that
the client talks too...

So does that help?

> 
>>    basic FTP model.  These examples use FTP for illustrative purposes.
>>    FTP was chosen since many of the basic concept are well known and
>>    should be familiar to readers.
> 
> 
> s/basic concept/basic concepts/
> 
> It's really great to find the example here. One could imagine it  being 
> in the overview as a motivator for the discussion, showing the  problem 
> space and how the solution addresses it.

Yep, I might want to use a better example but I am thinking
moving it up to the top of the document would be a good thing :-D

> 
>>    To effect a file transfer the following steps would take place.
>>
>>    1.  The application in PU(X) sends a login request.  The PU(X)'s  ASAP
>>        layer sends an ASAP request to an ENRP server to request the  list
>>        of pool elements (using (a)).  The pool handle to identify the
>>        pool is "File Transfer Pool".  The ASAP layer queues the login
>>        request.
> 
> 
> Dumb question from the guy who knows far too much about queues. Does  
> the ASAP layer queue it (store it in a FIFO, LIFO, or etc data  
> structure), or does it store it in a database of active requests? I  
> should think it would do the latter, so that the request could then  be 
> serviced as the necessary resources become available rather than  
> artificially making it wait for other requests whose resources don't  
> become available quite as rapidly.
Its the later I believe... but like I said FTP is probably
a bad example..

> 
>>
>>    2.  The ENRP server returns a list of the three PEs PE(1,A), PE (1,B)
>>        and PE(1,C) to the ASAP layer in PU(X) (using (b)).
> 
> 
> You need some punctuation there somehow. I tried, I have no idea how.
> 
Hmm yeah.. We need something.. its confusing at best :-(

R

> 

--

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Ong, Lyndon | 12 Jul 19:13 2006

FW: [Fwd: Re: Review: draft-ietf-rserpool-arch-11.txt] Baker comments

Randy's second response to Fred's comments.

L. Ong

Picon
From: Randall Stewart <rrs <at> cisco.com>
Subject: Re: Review: draft-ietf-rserpool-arch-11.txt
Date: 2006-07-10 13:49:46 GMT
Fred Baker wrote:
> On Jul 10, 2006, at 8:54 AM, Randall Stewart wrote:
> 
>> But without having read the rest of your email (I was replying and  
>> reading in real time)... does the basic concepts of what we are  
>> trying to do.. however poorly they were presented to you.. get  
>> through and make sense to you???
> 
> 
> Backing off and thinking hard, yes, I think can work most of it out.  
> Personally, I think that I shouldn't have to work that hard, but it  is 
> possible to eventually figure it out - after I have mentally  translated 
> the terminology into something else that makes some sense  to me. The 
> big thing is that now I have to remember the translations  and apply 
> them in real time as I read.

Then you and I agree.. I too keep a seperate terminology translation
in my head... its why I did NOT go much further than to add
a couple paragraphs to the INTRO section.. I did not "win" the
terminology discussion we had... so I constantly keep two sets
of terms (maybe more) in my head.. and thus am often times
confused when reading the architecture :-D

> 
> I didn't work out what a "pool user" was until I saw the FTP example  at 
> the end, and then I blanched a bit. So I am a random user of an  FTP 
> service, and I want to use the services of some remote set of  systems 
> that constitute a rserpool. I, the user (or his software) am  supposed 
> to know and care how some random service I access on the  Internet is 
> supposed to be structured?
> 
> For example, suppose that ftpeng.cisco.com consists of a stack of  
> servers. I have some pictures of Vint Cerf receiving the Order of  
> Saints Cyril and Methodius (comparable to the US Medal of Freedom)  last 
> week plus other activities in Bulgaria at ftp://ftpeng.cisco.com/ 
> fred/Sofia-7-3-2006-web/Sofia-7-3-2006-web.html. Suppose that I  provide 
> that URL to my wife, to use on our Mac at home. She plunks it  into 
> Safari, and the thing you would prefer to happen next is that  the Mac 
> wonders whether there is a server pool and starts with some  non-FTP and 
> non-DNS protocol to obtain a Pool Handle and then a Pool  Element Handle 
> to work out which server it should talk with, after  which it starts 
> using the appropriate FTPng protocol (based on BEEP)  to access the 
> pictures. My initial thought is - "not bloody likely".  The second 
> model, in which a proxy on site works it out, is more  palatable. The 
> Mac goes to the named machine (one of the addresses it  receives from 
> DNS), and if there is a load sharing activity going on  it acts as a 
> proxy to to real server behind it, or maybe changes  "its" address so 
> that the client is talking to the real server behind  it, as HTTP does.
> 
> I dare you to try to explain this expectation to my wife. Her eyes  will 
> glaze over at the mention of the computer...

I agree.. but of course if this is used for other things (not FTP) such
as call control engines or other FT devices where its really computers
using services (think my CDMA network I mentioned earlier)... then its
not an issue.. I don't think we have ever concentrated on trying to
make FTP/HTTP work over rserpool... except an example to try to
illustrate the concepts... Maybe we need a different example :-D

> 
> It would have really helped me if the examples were up front so I  could 
> see what you wanted to do, so that as I read the document I  could work 
> out how you were doing it.

ahh.. that would be interesting and maybe a better example :-D

> 
> I spoke with Pekka Savola last evening (while watching a soccer  match) 
> and mentioned passive voice; his comment is that folks for  whom English 
> is a second language would like to see passive voice  outlawed and all 
> users of it banished to a place of pain. I have  heard the same from 
> people whose first languages vary quite a bit -  Finnish in his case, 
> Japanese, Chinese, German, and so on. One of the  authors is German, and 
> maybe he will disagree with me.

Yes, I think Michael told me at breakfast he changed most of the
document to this voice... :-D

R

--

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Ong, Lyndon | 12 Jul 19:11 2006

FW: [Fwd: Review: draft-ietf-rserpool-arch-11.txt] - Baker comments

The attached message is part 1 of a series of comments from
Fred Baker as part of his review of Rserpool work.

L. Ong
Picon
From: Fred Baker <fred <at> cisco.com>
Subject: Review: draft-ietf-rserpool-arch-11.txt
Date: 2006-07-08 14:28:39 GMT
>    3.  What type of redundancy model will I use, 2N or N+K?

Is 2N a special case of N+K? I suspect that the key difference  
between the models is that the K extra servers in the one back up up  
to K failures among the N, where in the 2N case each of the first N  
servers has a designated failover server (all N could fail, and if  
the first N are serving a specific subset of the transaction set each  
backup steps directly up to that service set). But I can't tell this  
from your text. Should this be reworded to make the models more clear?

>    5.  How does a server assure that when it fails (or dies), the

s/assure/ensure/

>        clients will access the "best" server that is able to handle  
> the
>        failure (or if you will take over for the departed server)?

is that the server instance's responsibility, or the service's  
responsibility?

Let me give you an example. At one point I was talking with Paul  
Vixie about potential models for the DNS Root. At the time, instead  
of using distributed anycast servers, he had a number of servers on  
the same LAN at F Root and a single router in front of them. The  
router distributed load by hashing the source and destination  
addresses, and these all responded to the same destination address,  
so in effect the router was distributing by source address. I  
wondered whether he wanted us to look deeper into the packet and  
distribute based on some attribute of the name being looked up, such  
as a hash of the characters of the TLD. In this way, his servers  
would get a predictable subset. Should one fail, it would no longer  
be seen as a "next hop" in routing, and the hash would by definition  
distribute the load differently. None of this was ever implemented to  
my knowledge, btw. Butmy point is that in this case the service,  
which included a load distribution function in the router,  
distributed the load, but the individual servers had no knowledge  
that each other were there.

One way that a service can back up servers is to have the servers  
identify their backups. My point is that there are other ways, and I  
suspect they are more in keeping with your design.

>    A fault tolerant application needs to deal with these issues and  
> many
>    more.  Often an application is developed and then later, it is
>    realized that the application needs to be fault tolerant.  The
>    response to this new requirement mandates either a hack or re-write
>    of the application.

that comma doesn't make any sense. Would "Often an application is  
developed, and it is realized later that the application needed to be  
fault tolerant."?

>    So how can application writers solves these issues and makes it  
> easy
>    for the application designer to add fault tolerance without hacking
>    or rewriting the application code?

What, technically, is the difference between "hacking" and  
"rewriting" the code? Is "hacking" a bad job?

>    A second important point is that this layering no longer requires
>    each application to custom programmed for fault tolerance.  By

s/to custom/to be custom/?

>    3.  An application can be developed without a fault tolerant
>        requirement and later in the life cycle, if this requirement
>        emerges, it can be met with Rserpool without a costly redesign.

Suggestion: "An application can be developed in a manner that is not  
fault tolerant, and fault tolerance introduced later without a costly  
redesign by using Rserpool"

>    The above summary is the overall goal of Rserpool.

You have six goals, if I understood the text.

"The above summarizes the overall goals of Rserpool."

>    Each server pool is identified by a unique identifier which is  
> simply
>    a byte string, called the pool handle.  This allows binary
>    identifiers to be used.

Dumb question. Does the pool handle identify the pool of servers, or  
does it identify a server in the pool? It seems to me that there are  
uses for both forms of identifiers.

>    These pool handles are not valid in the whole internet but only in
>    smaller domains, called the operational scope.

What if the operational scope is the whole Internet?

It seems to me that "the whole internet" is a network layer  
description, while the operational scope is an application layer  
description. As such - and maybe it's just me - the above doesn't  
make a lot of sense.

Example: www.microsoft.com, if you look it up using nslookup, appears  
to be a service that is offered through a distributed redirection  
service to a variety of individual servers. I have no idea how many  
servers are involved or where they are located, but I get the idea  
that there is some DNS server that resolves that name with some  
knowledge of the source address, yielding something akin to what  
Akamai does with names, and without resorting to anycast routing  
(which IMHO would be a superior solution, but I digress). Now, the  
operational scope of the service is "anyone who might access  
www.microsoft.com", which is far too many end systems - it  
effectively IS the whole Internet. The pool handle in this case would  
seem to be implemented at the network layer, and is the address  
returned for the instance of that service that a given user will access.

So help me out here. What in the world is this "operational scope"?

>    In each operational scope there must be at least one ENRP server.
>    All ENRP servers within the operational scope have knowledge of all
>    server pools within the operational scope.

so, coming back to www.microsoft.com, let's suppose that it is  
implemented as some number of groups of servers, each group of which  
is co-located  in one of Microsoft's favorite service providers. You  
are presuming that there is at least one redundancy server in the  
service, and perhaps one or more in each such group of servers. So  
you are calling the groups of servers in a given colo location a  
pool, and the entire thing a service? Is that right?

>    Pool element: A server entity having registered to a pool.

This is a nice architectural term, I suppose. It doesn't help the  
reader much, though. The pool element is an instance of an  
application (in a virtual server, there might be many such running on  
the same physical hardware) that has registered with a pool server.  
Instead of focusing on the hardware it runs on (the server), could  
you call it an "application instance" or an "instance of an  
application", and the pool itself a pool of application instances?

I'm a humble engineer. I just make stuff work. When I define terms, I  
usually try to do so in a manner that will help me point to objects  
in pictures. So far, the terminology in this document has me  
completely lost. If you were to explain it in English...

> 2.1.2.  ENRP Servers
>
>    The second class of entities in the RSerPool architecture is the
>    class of ENRP servers.  ENRP servers are designed to provide a  
> fully
>    distributed fault-tolerant real-time translation service that  
> maps a
>    pool handle to set of transport addresses pointing to a specific
>    group of networked communication endpoints registered under that  
> pool
>    handle.

what is a "transport address"?

I can tell you what a TSAP is, or a TCEPID, if that is what you're  
getting at. A TSAP is the name a transport client uses to identify  
its connection to the transport, and a TCEPID is the name used to  
identify the transport in a a remote system when talking to the  
network layer and asking for connectivity (it translates to an NSAP  
and a multiplexing ID). In the IP architecture we don't talk much  
about those concepts, though - that's OSI. We generally talk about  
the network layer having addresses and the transport layer having  
ports, and when talking to a remote application we talk about the  
network address and transport port number that the application is using.

If that is what you're calling a "transport address", you'd best  
define the term. The text in this section about the destination  
address, protocol, and port might be a good starting point.

Or if you really mean an internet address, say so. We have enough  
confusion in the IETF with bellheads that call the physical layer the  
"transport". We don't need people misidentifying the internet  
sublayer of the network layer as the "transport" too. SCTP and TCP  
are transports - that's what the "T" stands for.

> 2.1.3.  Pool Users
>
>    A third class of entities in the architecture is the Pool User (PU)
>    class, consisting of the clients being served by the PEs of a  
> server
>    pool.

What on God's Green Earth is a "user" in this situation? Is it a  
person? An application? What?

> 2.2.2.  Aggregate Server Access Protocol
>
>    The PU wanting service from the pool uses the Aggregate Server  
> Access
>    Protocol (ASAP) to access members of the pool.

OK. So I'm a pool user (kid in a bathing suit, I think). I want to  
use your Rserpool thing to, I dunno, open a BEEP connection to an  
application in some other system. That means I'm going to open an  
SCTP connection (yes, Marshall never wrote down BEEP/SCTP, but he  
should have) to a given Internet address and transport port number,  
which will get me to that application. Do I have to also open an ASAP  
connection to a server to tell me which one to address? I thought I  
got that from DNS?

Or is the pool user someone else?If so, who?

>    o  The PE can send a business card
>
>    o  The PE can send cookies

these are defined terms, right? No, they are not defined in 2.3; 2.3  
merely says that they can be shipped around.

To me a business card is a small piece of paper, and a cookie is as  
defined in Betty Crocker...

>    basic FTP model.  These examples use FTP for illustrative purposes.
>    FTP was chosen since many of the basic concept are well known and
>    should be familiar to readers.

s/basic concept/basic concepts/

It's really great to find the example here. One could imagine it  
being in the overview as a motivator for the discussion, showing the  
problem space and how the solution addresses it.

>    To effect a file transfer the following steps would take place.
>
>    1.  The application in PU(X) sends a login request.  The PU(X)'s  
> ASAP
>        layer sends an ASAP request to an ENRP server to request the  
> list
>        of pool elements (using (a)).  The pool handle to identify the
>        pool is "File Transfer Pool".  The ASAP layer queues the login
>        request.

Dumb question from the guy who knows far too much about queues. Does  
the ASAP layer queue it (store it in a FIFO, LIFO, or etc data  
structure), or does it store it in a database of active requests? I  
should think it would do the latter, so that the request could then  
be serviced as the necessary resources become available rather than  
artificially making it wait for other requests whose resources don't  
become available quite as rapidly.

>
>    2.  The ENRP server returns a list of the three PEs PE(1,A), PE 
> (1,B)
>        and PE(1,C) to the ASAP layer in PU(X) (using (b)).

You need some punctuation there somehow. I tried, I have no idea how.

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool
Ong, Lyndon | 12 Jul 19:12 2006

FW: [Fwd: Re: Review: draft-ietf-rserpool-arch-11.txt] Baker comments

Attached is further discussion, part 3 in 
the series of messages.

L.Ong 

Picon
From: Fred Baker <fred <at> cisco.com>
Subject: Re: Review: draft-ietf-rserpool-arch-11.txt
Date: 2006-07-10 13:31:09 GMT
On Jul 10, 2006, at 8:54 AM, Randall Stewart wrote:
> But without having read the rest of your email (I was replying and  
> reading in real time)... does the basic concepts of what we are  
> trying to do.. however poorly they were presented to you.. get  
> through and make sense to you???

Backing off and thinking hard, yes, I think can work most of it out.  
Personally, I think that I shouldn't have to work that hard, but it  
is possible to eventually figure it out - after I have mentally  
translated the terminology into something else that makes some sense  
to me. The big thing is that now I have to remember the translations  
and apply them in real time as I read.

I didn't work out what a "pool user" was until I saw the FTP example  
at the end, and then I blanched a bit. So I am a random user of an  
FTP service, and I want to use the services of some remote set of  
systems that constitute a rserpool. I, the user (or his software) am  
supposed to know and care how some random service I access on the  
Internet is supposed to be structured?

For example, suppose that ftpeng.cisco.com consists of a stack of  
servers. I have some pictures of Vint Cerf receiving the Order of  
Saints Cyril and Methodius (comparable to the US Medal of Freedom)  
last week plus other activities in Bulgaria at ftp://ftpeng.cisco.com/ 
fred/Sofia-7-3-2006-web/Sofia-7-3-2006-web.html. Suppose that I  
provide that URL to my wife, to use on our Mac at home. She plunks it  
into Safari, and the thing you would prefer to happen next is that  
the Mac wonders whether there is a server pool and starts with some  
non-FTP and non-DNS protocol to obtain a Pool Handle and then a Pool  
Element Handle to work out which server it should talk with, after  
which it starts using the appropriate FTPng protocol (based on BEEP)  
to access the pictures. My initial thought is - "not bloody likely".  
The second model, in which a proxy on site works it out, is more  
palatable. The Mac goes to the named machine (one of the addresses it  
receives from DNS), and if there is a load sharing activity going on  
it acts as a proxy to to real server behind it, or maybe changes  
"its" address so that the client is talking to the real server behind  
it, as HTTP does.

I dare you to try to explain this expectation to my wife. Her eyes  
will glaze over at the mention of the computer...

It would have really helped me if the examples were up front so I  
could see what you wanted to do, so that as I read the document I  
could work out how you were doing it.

I spoke with Pekka Savola last evening (while watching a soccer  
match) and mentioned passive voice; his comment is that folks for  
whom English is a second language would like to see passive voice  
outlawed and all users of it banished to a place of pain. I have  
heard the same from people whose first languages vary quite a bit -  
Finnish in his case, Japanese, Chinese, German, and so on. One of the  
authors is German, and maybe he will disagree with me.

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool

Gmane