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.