[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Patrick <patrick@gandi.net>
Date: Wed, 29 Aug 2001 14:21:52 +0200
Content-Disposition: inline
In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60B84E4@vsvapostal3.prod.netsol.com>; from shollenbeck@verisign.com on Thu, Aug 23, 2001 at 07:10:13AM -0400
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Message Pushing and TCP Transport

On Thu, Aug 23, 2001 at 07:10:13AM -0400, Hollenbeck, Scott took time to write:
> >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.
> 
> The "without queue overhead" statement is true only if the pusher has no
> intention of retrying in case of failed delivery.  Push or poll, the sender
> needs to do something in response to an unresponsive recipient.  In case of
> failed delivery, the sender can either drop and discard the message
> completely, or it can queue the message for a later delivery attempt.  I
> suspect the "queue for later delivery" option will be more reasonable, and
> thus push/poll end up having similar queue resource requirements.

I totally agree with Scott on this point.

> If, on the other hand, folks are comfortable with the idea of trying to push
> a message once and throwing it away if it isn't delivered, then there is
> indeed no queue overhead to worry about.

I am interested to have explanations by people wanting the PUSH.
As far as I see in draft-brunner-xrp-01.txt (but maybe I'm not
looking in the right place, if this is the case, do not hesitate to
forward me) there is no technical explanations on how the push should
work.

It raises me questions like :
- when a Registrar is connected multiple times, on what connection
the Registry will push ?
- will the Registry wait for an ACK after the push ? what will be
done if it is not received ? will the messages be pushed later ?
how many times ? dropped ? when ? how ?

As far as I see things now we have a POLL mechanism totally described
and without more overhead than a PUSH (state of the queue is given as
results of other successfull commands), and no details about a PUSH.

This is why I am totally uneasy with adopting the PUSH mechanism.
From what I see, I see no benefits.

Patrick.

Home | Date list | Subject list