Re: [dhcwg] Spencer Dawkins' No Objection on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with COMMENT)

[Kim Kinnear <[e-mail]>]

Spencer,

Thanks for explaining your concern.  I'll respond below...

On Oct 2, 2015, at 8:57 AM, Spencer Dawkins at IETF <[e-mail]> wrote:

> Your response helped quite a bit.
> 
> I guess I'm not understanding why having the server bail when the client can't read responses fast enough makes sense. I would kind of expect that the first thing the client would do when the connection closes is to open a new connection and try again (because the client still needs the information). Would you expect the client to give up for a while before retrying?

	No, I would expect that the client would reconnect with
	catch-up.

	You have asked an interesting question, and caused me to
	reflect on why we put this into the draft.

	If a requestor (client) can't keep up with the server it will
	cause the server to remember increasing amounts of information
	on its behalf.    The section we are discussing deals with the
	situation where the requestor is running so slowly (or is hung
	in some way) where the server is unable to queue anything to
	the TCP connection for two minutes.  When this happens, the
	server drops the connection.

	This is a way of saying "Enough, already!" by the server.  It
	isn't designed to give the requestor a break, particularly.
	It is more designed to illustrate to those who may be
	monitoring either of these two entities (server or requestor)
	that something serious has gone wrong.

	Otherwise a hung requestor could sit around for days and
	nobody might notice.  Of course a well written server would
	notice at some point that it has too much stuff backed up and
	will terminate the connection or raise a signal or something.
	That isn't part of the protocol, but would be part of a
	reasonable implementation.

	The part that is part of the protocol is this bit where 
	*something* has to flow during a two minute period or we
	assume that things are broken.

	......

	For what it is worth, we expect that there is only one client
	for this information per server.  More would work, but generally
	we don't see why you would want more.

	Thanks for digging into this!

	Regards -- Kim

> 
> On the other hand,
> 
> - you may be solving a problem that you've encountered in practice, which would be fine, and 
> 
> - the meta-answer may be that you think this is happening because the client is more overloaded than the server, so giving the client less to do while it's overloaded is the right answer, and 
> 
> - the meta-meta-answer may be that you're not expecting lots of clients to be asking the server for this information in the first place, so if you're using TCP, not much can go wrong, transport-wise.
> 
> But I was surprised :-)
> 
> Thanks again for helping me with this.
> 
> Spencer