Subject: RE: [Rserpool] WG Last Call on Rserpool Requirements

From: [email-masked]
Date: Fri, 20 Apr 2001 12:27:44 +0300

Hi Qiaobing,

> To my understanding, the other document is just going to be a 
> summary on
> what we've talked about on the list plus what was pulled from the old
> requirements document (unless John is planning to add some substantial
> new material to it, John?). 

I am taking what was removed from the old draft and updating it with some
of the recent DNS discussion. I'm halfway through it right now ...

John

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

---

From: "Guo, Xingang" <[email-masked]>
Date: Fri, 20 Apr 2001 16:33:31 -0700

I also posted some comments on Sec 2.7 a few days back, am afraid it was
shadowed by the battle of DNS vs. ENRP.
Here it goes again.

Section 2.7 Timing Requirements: "A server pool can consist of a large
number (up to 500) of pool elements."

Why 500?  I think the motivation of an upper limit is to provide a delay
bound to "real-time" name resolution.  If no such delay bound can be
guaranteed, then "real-time" doesn't make sense at all, which further makes
the number 500 even more ad-hoc.  So why not say something like,

"A server pool can consist of a large number of pool elements.  However, the
architecture will provide bounded delay in handling real-time name
resolution."

Moreover, "bounded delay" is closely relevant to the next paragraph which
talks about PE supervision.  In order to maintain a list of operational PEs,
the server status has to be updated periodically (by name server or PE).
Delay bound governs such update interval, while number 500 can not.

Cheers,

--Xingang

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Friday, April 20, 2001 4:13 PM
> To: Qiaobing Xie
> Cc: [email-masked]; [email-masked];
> [email-masked]; Randall R. Stewart
> Subject: Re: [Rserpool] WG Last Call on Rserpool Requirements
> 
> 
> Qiaobing,
> 
> Here's an example.
> 
> Section 2.7 does not give sufficient detail to understand 
> what the timing
> requirement is.  What's fast?  By understanding why DNS 
> doesn't meet that
> requirement perhaps we can articulate it better.  What 2.7 
> DOES talk about
> is the number of pool elements, but that's insufficient to 
> understand what
> the timing requirements are.  What is the property that we 
> need from a new
> mechanism that the existing mechanism lacks?  That's what I 
> come back to.  
> 
> There are a number of requirements that are listed in the 
> draft that have
> no stated reason for their being there.  Now there was some 
> discussion,
> but not in the document.  For instance, see section 2.10.  
> Why are pool
> handles, as opposed to names, a requirement?  Why are we scoping these
> things the way we are in the requirements document?
> 
> So I guess I want two things:
> 
> 1.  More precise requirements
> 
> 2.  A good argument why existing mechanisms don't work.
> 
> I think that if you do either sufficiently well you get the other for
> free.  Right now I'm not comfortable with either.
> --
> Eliot Lear
> [email-masked]
> 
> 
> Qiaobing Xie wrote:
> > 
> > Eliot,
> > 
> > I am completely lost here. You are talking about solutions 
> but I think
> > we are still working on the requirements.
> > 
> > IMO, we need to first clearly lay out what Rserpool 
> requirements are.
> > After that, if it turns out that some existing technology 
> (e.g., DNS,
> > DNS+, etc.) meets all the identified requirements, it would 
> be wonderful
> > - we won't need to invent another protocol.
> > 
> > But at this point, I agree with John, requirements are 
> requirements and
> > they don't change no matter whether DNS is an adequate 
> solution or not.
> > 
> > regards,
> > -Qiaobing
>