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

From: Kim Kinnear <[email-masked]>
Date: Thu, 1 Oct 2015 11:20:47 -0400

Spencer,

Thank you for reviewing the draft.

My comments are in-line, below...

On Sep 30, 2015, at 3:43 PM, Spencer Dawkins <[email-masked]> wrote:

> Spencer Dawkins has entered the following ballot position for
> draft-ietf-dhc-dhcpv4-active-leasequery-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for including a lot of TCP-awareness in this specification.
> 
> I had a few questions, but nothing at Discuss level. If you have
> questions about my questions, please ask, of course.
> 
> In this text, 
> 
>   A requestor attempts to establish a TCP connection to a DHCPv4 Server
>   in order to initiate a Leasequery exchange.  If the attempt fails,
>   the Requestor MAY retry.
> 
> you might want to give some guidance about reasonable intervals to wait
> before retrying, randomizing retry intervals, and/or backing off retry
> intervals to some conservative maximum value. This isn't a
> general-purpose client-server protocol, and you understand the use case
> better than I do (and I wouldn't try to offer defaults), so please just
> consider whether this would be helpful.

	Both you and Ben Campbell seem to think this is important.
	I will add: "Retries SHOULD NOT be more frequent than one
	every ACTIVE_LQ_IDLE_TIMEOUT (Section 5.3)."
> 
> In this text,
> 
>   In any of the first three possibilities, the DHCPv4 server can be
>   assumed to not support TLS.  In this case, the requestor MUST close
>   the connection.
> 
> is the assumption that all three possibilities would happen again if you
> retried the attempt with the same server? I wondered especially about the
> second possibility (server side TCP connection close, as a possible
> load-shedding strategy to reject a connection request that might work at
> another time).

	Wow, good question.  I think that all three would happen again
	if you retried the attempt.  I believe that load-shedding would 
	reject the TCP connection altogether, or it would reject the
	ACTIVELEASEQUERY message.  I don't see that rejecting the TLS
	connection would buy anyone anything.  I'll put a sentence in
	Section 8.1 saying:

	"If a connection is to be rejected because of a limitation of
	the number of open connections, the TCP connection itself should
	be rejected, or the ACTIVELEASEQUERY message should be rejected.
	Capacity related rejections SHOULD NOT affect the response to the
	DHCPTLS message."
> 
> In this text,
> 
>   The Requestor attempts to read a DHCPv4 leasequery reply message from
>   the TCP connection.  If the stream of replies becomes blocked, the
>   Requestor SHOULD terminate the connection after
>   ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
>   to do so.
> 
> I'm not sure what "becomes blocked" means from the Requestor's
> perspective. I'm guessing the following paragraph, describing interaction
> with DHCPLEASEQUERYSTATUS, is the clue I'm missing, but if so, reversing
> the order of the paragraphs, and tying that more tightly ("becomes
> blocked, with no DHCPLEASEQUERYSTATUS messaging", or whatever the clue
> I'm missing is), would likely be clearer.

	I'll switch the paragraphs.
> 
> I have pretty much the same question about the corresponding text for the
> server side in 8.1,
> 
>   If the TCP connection becomes blocked while the server is accepting a
>   connection or reading a query, it SHOULD terminate the connection
>   after a BULK_LQ_DATA_TIMEOUT.  We make this recommendation to allow
>   servers to control the period of time they are willing to wait before
>   abandoning an inactive connection, independent of the TCP
>   implementations they may be using.
> 
> and in 8.2,
> 
>   If the connection becomes blocked while the server is attempting to
>   send reply messages, the server SHOULD terminate the TCP connection
>   after ACTIVE_LQ_SEND_TIMEOUT.  This timeout governs how long the
>   DHCPv4 server is prepared to wait for the requestor to read and
>   process enough information to unblock the TCP connection.  The
>   default is two minutes, which means that if more than two minutes
>   goes by without the requestor reading enough information to unblock
>   the TCP connection, the DHCPv4 server SHOULD close the TCP
>   connection.

	This is all about the requestor not being able to process
	replies quickly enough, and the server getting backed up and
	backed up waiting to send messages.  It won't wait forever,
	and that is what these paragraphs are about.  I'm not sure
	exactly what the concern is about these paragraphs, so I'm not
	sure just what to do about it.

> 
> This text 
> 
> 8.3.  Multiple or Parallel Queries
> 
>   Every Active Leasequery request MUST be made on a single TCP
>   connection where there is no other request active at the time the
>   request is made.  Note that this is different than what was allowed
>   in [RFC6926] section 7.7 for Bulk Leasequery requests.
> 
> and the following two paragraphs are good, but I didn't see any
> corresponding description of whether parallel queries were allowed on a
> single TCP connection in Section 7, for Requestor behavior, and the
> Requestor would be the entity that does this wrong, wouldn't it? Or did I
> miss it?

	You are correct.  We used to allow parallel queries, but one
	of the reviews had us remove it.  In removing it, we probably
	didn't say that you couldn't do it from the requestor's standpoint.

	I'll add the sentence below to Section 7.1, General Processing 
	for the Requestor:

	"Only one ACTIVELEASEQUERY is allowed on any one TCP connection
	at a time.  Parallel ACTIVELEASEQUERY requests on the same TCP
	connection are not allowed."

> 
> I've seen some use cases described in IESG evaluation e-mail that sounds
> like the Requestor and DHCPv4 server are close enough for a human to
> touch both at the same time, but Kathleen commented that some ISPs
> provide DHCP service to customer edge routers. Is it worth saying
> anything about firewalls and NATs treating TCP differently? Or would even
> those cases be part of a trusted network path, so no firewalls or NATs?

	I expect that if someone does DHCP at a customer edge routers
	that they have built a trusted path to get there.  Possibly
	not, though.  I don't know enough about the common aspects of
	such deployments (assuming that such common aspects even
	exist) to create useful guidance in this draft.  It would be
	easy to make assumptions that don't hold in many cases,
	resulting in more confusion than enlightenment.  I'm going to
	remain silent on this issue.

	Thanks much -- Kim

> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 2 Oct 2015 07:57:58 -0500

Hi, Kim,

Thanks for the patient responses! I had one thing I wanted to better
explain (now that you've helped me understand what's going on better), but
no need to reply, after you think for a minute ...

On Thu, Oct 1, 2015 at 10:20 AM, Kim Kinnear <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

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?

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

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 2 Oct 2015 11:30:08 -0400

Spencer,

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

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

> 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 :-)
>