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
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
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)
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
Full text of Randy's response L. Ong
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
Third response from Randy. L. Ong
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
Final response from Randy. L. Ong
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 bestR > -- -- 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
Randy's second response to Fred's comments. L. Ong
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
The attached message is part 1 of a series of comments from Fred Baker as part of his review of Rserpool work. L. Ong
> 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
Attached is further discussion, part 3 in the series of messages. L.Ong
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
RSS Feed1 | |
|---|---|
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
2 | |
3 | |
1 | |
3 | |
4 | |
7 | |
10 | |
1 | |
29 | |
14 | |
6 | |
13 | |
7 | |
6 | |
4 | |
10 | |
12 | |
2 | |
2 | |
12 | |
10 | |
6 | |
10 | |
2 | |
1 | |
1 | |
3 | |
5 | |
1 | |
6 | |
10 | |
2 | |
2 | |
12 | |
6 | |
3 | |
1 | |
7 | |
6 | |
1 | |
6 | |
2 | |
19 | |
37 | |
15 | |
1 | |
4 | |
11 | |
4 | |
6 | |
5 | |
28 | |
3 | |
15 | |
30 | |
5 | |
6 | |
6 | |
3 | |
1 | |
5 | |
18 | |
26 | |
13 | |
13 | |
7 | |
8 | |
33 | |
19 | |
5 | |
14 | |
17 | |
25 | |
7 | |
7 | |
30 | |
29 | |
18 |
