Subject: [Rserpool] comments to ASAP.. and a few for ENRP

From: Randall Stewart <[email-masked]>
Date: Mon, 26 Jun 2006 13:50:38 -0400

Now here is what I picked off at 30,000 feet... Friday..
and I added one more at the end that I detected as
I was implementing... Notice that term.. considering
I am not done implementing and still generating comments..

I think there will be more comments as I finish
implementing.. and a bunch of comments (besides the
few I make here) when I get to implementing ENRP...

---------Comments----------------------

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)
--------------------------------------------
Section 2.2.10

The server idenity field is confusing.. it is actually
(from at least what I can tell and what I remember) a
32 bit field.. yet it appears in the document to
be a TLV.. it should not be. 

Note also I researched this a bit in ENRP as well
and there seems to be multiple names used for the
same field.. this needs to be consistent (so here
is an ENRP comment.. I guess I lied :-D)

--------------------------------------------

End of Section 2... and a confusion on my
part. No where in asap can I find a specific
directive that the way you tell ASAP vs other
things is in the PPID field from SCTP (or
its equivalant tcp adaption thingy). Now
this should be spelled out here.

Secondary question.. should we not have
an ENRP related PPID as well? Or is
that really needed since the ENRP deamons
can setup seperate sockets to deal with
inter ENRP comm?

--------------------------------------------

Section 3.4

There is no specification of how your
home server changes. This should be explictly
stated. In general an ASAP client should be
promiscuous.. any time a HB comes in from
an ENRP server, that should become the
new home ENRP servers. ENRP servers themeselves
end up agreeing on who owns whom.. and thus
only one will send a HB.. normally where 
you orginally registered at. Now also we 
need comments about the "subscribe for update"
that we wanted to do in here somewhere too.

I.e. I can ask for dynamic updates to any
pool handle reg/de-reg as a client. A change
occurs and the ENRP home server pushes it
out to me.. but of course a change of 
home server forces a re-reg of this request
since ENRP does not share who is getting
pushed data. 

This all needs to be put in both ENRP and
ASAP.. so far its un-specified.

-------------------------------------------

3.6 server hunt...

states:

   SH1) The PE or PU SHOULD try to establish an association or
      connection with no more than three ENRP server addresses.  An
      endpoint MUST NOT try to establish more than three association or
      connections at any single time.

RRS:different or the same guy (3 addresses)? What
I think we want is 3 unique ENRP servers.. not
3 addresses.. since an ENRP server can and should
be multi-homed :-D

Also this section states:

     SH5.1) The endpoint MUST double the value of the T5-Serverhunt
         timer.

RRS: What caps the doubling.(RTO.Max?). or does it just go on and on? And
     for that matter, why double with a 120 second timer? It
     really is so SLOW I think we should NOT double it

     Note in TCP/SCTP RTO.Max is 60 seconds...

-------------------------------------------

3.7.1 send failure

states:

   In such a case, the ASAP endpoint should not re-send the failed
   message.  Instead, it should discard the failed message and start the
   ENRP server hunt procedure as described in Section 3.6

Should it not also note the action it was after and
queue this to use once you find a new enrp server? Aka
if you are requesting resolution of pool name X, should
you not indicate to the request (there is a timer running
there) that you are now getting a new name server.. and then
after that occurs, resubmit the request? You should
but this is not clearly defined...

It is also not clear what you do in case C i.e.
a registration failure. This should be specified
(fix what is wrong if you can deduce it and
 retry.. or report to the user the failure)

----------------------------------------

5.1 default values

   T5-Serverhunt - This timer is used during the ENRP server hunt
      procedure and is normally set to 120 seconds.

RRS: This is way to big if your doubling

---------------------------------------

5.3 states:
   MAX-REG-ATTEMPT - The maximum number of registration attempts to be
      made before a server hunt is issued.

RRS: So what is the default.
and

   MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made
      when requesting information from the local ENRP server before a
      server hunt is issued.

RRS: So what are the default values for the above three items??

---------------------------------------

Another issue.. PE-Id..

The value is globally unique to all
pools? Or should be. We need to specify
this very clearly... the fact that
there is a home-enrp-server id in
the pe info is confusing. It makes one
wonder if the home-enrp-server+pe-id
is unique OR is it just the pe-id which
is unique?? 

I think we wanted pe-id unique alone, so
in such a case maybe the name resolution
response message should have the home-enrp-server
id set to 0 for the responses to the PU's and
PE's... I think the field is there for use
in ENRP.. but for ASAP we don't need to
see this field.. it is confusing and it
actually gives away a bit of information.

Maye ENRP should say something about this
field MUST be set to 0 in the response message
to a name resolution request...

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 28 Jun 2006 09:42:27 -0400

All:

And another thought as I work through implementing
the PE/PU side stuff..

In the Pool Element are two sets of transport
addresses:

User Transport Param

ASAP Transport Param.

Now, the ASAP param must be SCTP...

What is the purpose of this entry?

The document is not clear and, in thinking about its uses
I can come up with a couple of  scenario's none of which I like:

a) The ASAP TP is the communication endpoint used by the
    PE to register and talk to the ENRP server... problem with
    this IMO is that the PU does NOT need this information! Now
    it may be here implicitly since ENRP and ASAP use the
    same message format.. if so thats ok.. we just need to
    make sure the parameter is NOT sent in a name-resolution-resp
    by the ENRP server... this needs to be documented if so..

b) The ASAP TP is used when the peer has a different DATA transport
    (say UDP) and wants to still communicate with ASAP.. i.e. we
    end up with seperate control and data connections/paths.
    This, I think, is the real purpose of this info.. and I don't
    like it one bit. Why, it really becomes a mess if you allow
    seperate PU <-> PE data and asap communication. The issue is
    coordination. We have, over the PE<->PU control side a number
    of messages (COOKIES, BUSINESS-Cards ... etc).. The COOKIE, for
    example, needs to arrive first.. ahead of anything else to assit
    the PE in building state... But coodinating between two transports
    is a royal pain.. and much more difficult.  IMO if the user wishes
    to use UDP for DATA only, then thats ok.. they work at a more
    primitive level.. and don't get all the benefits necessarily...

If the transport for data is control+data then no matter how you
slice it in the case of <b> its redundant .. since it should contain
the same information...

So, I think we should cut the ASAP transport parameter out of the
PE message unless ENRP uses it between its peer servers... have
not looked at that aspect.. but if its for multiple connections
between PU-PE.. I think it will be more headache then usefulness.

Comments??

R