Re: Message Pushing and TCP Transport

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Dan,

> ... <someone> will be using a (hold-down timer) 5 day waiting period.
and
> ... <someone else> is considering (no hold-down timer) forgoing the
> transfer wait period with the reasoning that the auth info from the 
> registrant is enough to consider the transfer ligit.

Correct, so far as I keep track of the someone's and their business rules.

The protocol issue is are we doing the right thing by making a non-zero
hold-down timer manditory? I don't think so, it is overspecification.

I'll pass on the comparisons of US and Canadian Universities, you have
the better beer, not really a challenge that, and besides, I took my degree
in maths at Berkeley, so of necessity, the rest is left to the reader ...

> Having the registry purge old/expired notifications and bulk emailing 
> them to the registrar isn't such a bad idea.

Both here, and earlier where you mention guidelines, in effect you've put
a portion of the state machine outside of the available mechanisms we are
describing in a protocol. Old and expired are relative terms, and how do
we know these aren't (somewhere) equal to new and current? add/mod/del by
protocol, notify by postal worker... 

> >Broadly, we're looking at the scaling properties of the protcol
>
> I don't quite understand what you are saying here.  Polling isn't 
> scalable?  How? 

As you alluded to in your earlier message

> system that's already very busy trying to handle thousands of 
> domain:check commands and domain registrations, and DNS updates, and....  

poll is only one component of the message flow between a registry and its
registrars. As you also alluded, significant load, if only from checks, is
a given. Additionally, bursty, resource exhausting behavior is known to
exist in the NeuStar number portability data base and Verisign .com registry,
both having poll-only state management mechanisms.

If there is one thing we do know, it is that a registry may push state to
a registrar, without queue overhead, or hold-down timer complications and
secondary access and store overhead. We also know, as Scott pointed out in
the sections I quoted, that deferred queue service causes registry resource
consumption.

Queue service with arbitrary deferral by readers has different limiting
properties than queue service without deferral.

My note to Jordyn from April 9th from that other list is my best attempt
(YMMV) to state the issue:

> Date: Mon, 09 Apr 2001 20:09:16 -0400
> Reply-To: foobarbaz@yahoogroups.com
> Subject: Re: [foobarbaz] Notifications - Pull / Push 
> 
> In our model we've a registry with some number of registrars concurrently
> managing state, and just to keep things on the back of a napkin, I'll use
> the numbers 1 and 67 for the respective cardinalities.
> 
> One choice, which looks a lot like a common real-time event model, is to
> poll the state manager for state transition data. Another choice, which
> looks a lot like a common time-sharing event model, is to interrupt the
> state transition clients.
> 
> We usually observe that when building network subsystems (my background)
> that livelock avoidance skews us towards the first design point, but the
> number of state transition participants is usually quite small, usually
> four or fewer.
> 
> What we should anticipate with an event-poll model is that the server will
> experience periodic synchronous load events that are event-poll artifacts
> having no corrolation with actual state transitions. What we should also
> anticipate with an event-interrupt (push) model is that the server will not
> experience such events, regardless of the number of state-transition clients.
> 
> The complication, as I've pointed out previously, is server-side connection
> initiation. However, it scales, like multicast.
> 
> The simplification of polling of course is two-fold, the first as has been
> observed, and the second is that it doesn't scale, so the asymptotic server
> behavior may keep the number of registrars a registry can economically feed
> down to something not much different from the present.
> 
> Does anybody care if server-side polling overhead limits the number of
> client-side pollers? Not having been an RRP registry operator, registrar,
> or reseller, we've an opinion, but it isn't an informed one.

Scott has made responsived comments to this.

... transfer, billing, outages, watch ... elided

> >How do you propose to solve these?
>
> Again, pardon the injection of "process" here,

Nope. Fish or cut bait. Either these are technically interesting questions
for which you've got answers, even if they are of the form "use some other
protocol", or you don't. If we were to put down our pencils at the first
point where money is made, rather than complete the protocol, we would do
so _before_ transfer, delete, or modify, and fob that off onto the other
protocol, whatever that is. Standards have costs that propritary solutions
don't have -- the cost of time and the benefit of scrutiny and correctness.

> which means the developement of heterogeneous 
> registry agents by registrars

Didn't you get to this conclusion simply by reading 2.9.2.3? Every operator
can set timers and pick OOB mechanism(s) and discard behavior(s).

> (what the defunct list, [1], was trying to 
> avoid all along).

Milage varies. I didn't think that was the purpose of that botch. It was
to demonstrate the possibility of technical cooperation. The form was not
material. The result was conclusive. EOL.

Eric