Re: Pool Handle Translation in draft-ietf-rserpool-enrp-06.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 23. September 2003 00:18 schrieb Qiaobing Xie:
> Hi, Thomas,
>
> To add a "more data" flag to NAME_RESOLUTION_RESPONSE will add
> complexity to the implementation and add significant delay to ENRP query
> responses when the flag is used. To allow the use of "an appropriate
> subset of PEs" will raise the question (and ambiguity) of "what is the
> appropriate subset of PEs", and will break the load sharing mechanism,
> and may potentially cause inter-op problems. IMO, either change above
> would need a very strong justification to make.
>
> Let's do a little calculation to see how big the problem you mentioned
> is.
>
> With 16 bit length field, you are allowed to have a 64k byte size
> response msg.
>
> a) if each PE in the pool is of SCTP type with dual-homed IPv6
> interfaces, a PE param TLV would take 72 bytes, and you would be able to
> comfortably fit about 900 PEs in a response;

But what happens when some PEs register e.g. with 100 IPv6 addresses or more. 
This can cause a denial of service! Another way to cause a denial of service 
would be to fill up the pool with registrations until a 64K response msg is 
reached. 


> b) if each PE is of SCTP type with triple-homed IPv6, a PE TLV would
> take 92 bytes and you would be able to have >700 PEs.
>
> For IPv4 or transport type other than SCTP, you could easily get >1000
> PEs in a single response message.

Replying many PEs in a single response message is also quite inefficient. 
Consider a PU connected to the Internet via a 28800 baud modem. Transfering a 
64 KBytes chunk takes more than 20 seconds. Via GSM or GPRS, this would not 
only be slow but also very, very expensive.  And usually, it can be expected 
that the PU gets connected to a PE after trying very few PE addresses. Since 
the PEs in the PU's local cache also time out, transfering many PEs does not 
make sense.


> We talked about RSERPOOL scalability issues a long time ago and I
> remember our consensus was to be able to support pool size in the range
> of no more than 150~200 PEs as our requirement.
>
> So I am not convinced that the message size limit here is causing a
> problem for us.

Well, most pools will probably not exceed a 64K size limit. But the protocol 
design should not build such a limit in. May be, in some years this will 
become a problem. What about "In the response message, the ENRP server 
*SHOULD* list all the PEs currently registered in this pool, in a list of PE 
parameters." instead of MUST?


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 protected]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/cAVC32BbsHYPLWURAvF2AJ9vwr4P6KACBmfd+GF4MxxDLfFzywCdHZHD
FXn89NT4UVVehvOLcf8dlM4=
=SB1H
-----END PGP SIGNATURE-----