Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt

From: Qiaobing Xie <[email-masked]>
Date: Thu, 19 Sep 2002 17:34:21 -0500

Hi, Thomas,

Sorry for the late response, both Randy and myself were taking vacation. Pls see
my comments in-line..

Thomas Dreibholz wrote:
...
> some comments on draft-ietf-rserpool-asap-04.txt:
> 
> - - DEREGISTRATION_RESPONSE:
> The "Pool Element Parameter" field must be optional, since the nameserver
> cannot generate this field if the pool element identified by Pool Handle
> Parameter and PE Identifier Parameter in a DEREGISTRATION message is not
> existing in the namespace.
> There should also be an error code (e.g. 7) for "Pool Element not found".

Agreed. In fact, I'd suggest to replace the PE TLV with a PE Identifier TLV in
both reg and de-reg responses. Building the PE TLV again from parsed attributes
when sending the response is really a pain, while simply mirroring the original PE
TLV back does not seem to serve any purpose. 
 
> - - There must be an error message type for the case of an unknown message type
> is received. For example, a client sends a message type 0xab to the
> nameserver. This type is unknown, therefore an error should be returned.
> Suggestion:
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Type = 0xff | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Message Length +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Error Parameter                                              +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

A PEER_ERROR message is defined in ENRP v04 already. Probably the same needs to be
done for ASAP. Since ENRP and ASAP are on different paths, they need to define
their error message separately.

> 
> - - NAME_RESOLUTION_RESPONSE, ENDPOINT_KEEP_ALIVE_ACK, COOKIE_ECHO,
> SERVER_HUNT_RESPONSE must contain an optional "Operational Error" parameter.

Sounds reasonable. In addition, with NAME_RESOLUTION_RESPONSE + Op Error, we
probably can remove NAME_UNKNOWN.

> - - There should be the pool policies "Random" and "Weighted Random":
> Random:
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Param Type = 0x6             | Length = 8                    +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Policy Type = 0x5 | Weight                                   +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

this makes sense and is straightforward to add.

> 
> Weighted Random:
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Param Type = 0x6             | Length = 8                    +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Policy Type = 0x6 | Weight                                   +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> The format of "Weight" should be the same as for weighted round robin. To be
> defined.

more justification may be needed for this one. Seems quite computation intensive
to match a distribution function.

> 
> - - Section 3.6.4:
> WRR uses Weight, not Load.
> 
> - - Error codes:
> There should be a code for "Out of memory", e.g. 8.

"out of resource" may be better.

> 
> - - SERVER_HUNT_RESPONSE should contain at least one Server Information
> Parameter. This is useful for 2 reasons:
> 1. The nameserver may use a port different from the well-known nameserver
> port.
> 2. The nameserver may support SCTP and TCP or SCTP only; some pool users may
> only support TCP and therefore are only interested in TCP-capable nameservers.

I am not sure about this one. I guess I don't quite see your scenario here. If a
nameserver is listening on a different ASAP port and the PE is doing the hunt by
the well-known port, the server will never receive the server_hunt in the first
place. If the server is responding, then it means that the PE did the hunt on the
right port. Secondly, if a PE is TCP-only, it will by definition only do the hunt
over TCP and any server that responds to the PE is by definition TCP-capable.

BTW, adding Server Information TLV won't work since it is defined for ENRP only,
i.e., it does not contain ASAP side information, such as the server's ASAP port #
and ASAP transport support.

> 
> - - SERVER_HUNT should have a parameter stating the required transport protocol
> of the sender (SCTP or TCP, SCTP only, TCP only). It does not make sense for
> SCTP-only nameservers to reply to pool users requesting TCP-only.

ditto.

> 
> - - A well-known port number for the nameserver has to be obtained.

Yes. At the end, we will have a well-known ENRP port and a well-known ASAP port
for the server.

regards,
-Qiaobing

> 
> Best regards
> - --
> =======================================================================
>  Dipl.-Inform. Thomas Dreibholz
> 
>  University of Essen,                            Room ES210
>  Inst. for Experimental Mathematics              Ellernstraße 29
>  Computer Networking Technology Group            D-45326 Essen/Germany
> - -----------------------------------------------------------------------
>  E-Mail:     [email-masked]
>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================
>
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 19 Sep 2002 17:34:21 -0500

Hi, Thomas,

Thomas Dreibholz wrote:
...

ditto.

regards,
-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Fri, 27 Sep 2002 07:48:13 -0500

> Sorry for the late response, both Randy and myself were taking vacation. Pls see
and overworked in other areas :-<

> TLV back does not seem to serve any purpose. 

I agree too

> their error message separately.

Either that or more fodder for the common parameters document...

> probably can remove NAME_UNKNOWN.

True.. sounds good

> to match a distribution function.
Well probably one could call the 'least used' a weighted distribution 
since you are really talking that the weight is what the least used
is looking at :>

> "out of resource" may be better.

yes sounds good that way it is more generic

> over TCP and any server that responds to the PE is by definition TCP-capable.
Wait a minute. PE's have a requirment to register and use SCTP. At least 
I thought so.. when did this change? The PU can use TCP so maybe the
comments are good for PU's but I don't think they apply to PE's.

> and ASAP transport support.
agree

> Yes. At the end, we will have a well-known ENRP port and a well-known ASAP port

Why do we need a "well known" ASAP port number. Do you mean a ASAP port
for the name server to listen on? If so I agree...

Also I think these will be a dual reserved port in TCP and SCTP space so
why would a nameserver listen on any other port?

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Fri, 27 Sep 2002 07:48:13 -0500

I agree too

True.. sounds good

agree

R