Subject: [dhcwg] Mirja Kühlewind's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Thu, 02 Feb 2017 06:44:12 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dhc-dhcpv6-failover-protocol-04: 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-dhcpv6-failover-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few questions that are not fully clear to me and maybe need some
additional explanation in the draft (or maybe it's just me...):

- It's not fully clear to me when a TCP connection is opened or closed.
Are the two servers supposed to have one long-lived connection? And if
that connection is terminated for any reason, should the primary server
try to re-open immediately? And if a (new) connection is (re-)open do I
always need to send a CONNECT first, or only if I didn't have any
connection with this server before? And if the secondary server goes down
and comes up in RECOVER state (sec 8.5.1.), should it open a TCP
connection to the primary server, or will always the primary server be
the one that opens the connection (and if so when will it do it)?

- Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD  is
needed and how the server should know the right value. I guess you would
want to calculate this based on the send buffer, however, not all message
have the same size and as such I don't know how to calculate that. And is
that really needed? If messages will not be accepted by the receiver-side
server, the receive window will be zero and the socket on the sending
side will be blocked; no additional message can be send. What will be
different if the sender knows in advance when it could potentially happen
(but also might not if the other end processes the messages quickly and
there is no excessive loss).

---

From: kkinnear <[email-masked]>
Date: Thu, 2 Feb 2017 11:25:55 -0500

Mirja,

Thanks for your review.

I'll respond to your questions directly, indented, below...

> On Feb 2, 2017, at 9:44 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 

	I would have thought that this was spelled out, but as I look
	at the draft I see that it isn't all that explicit.  While I
	could answer your questions directly, let me instead offer a
	new paragraph which tries to answer these questions for not
	just you but other readers of the document:

6.  Connection Management

   Communication between failover partners takes place over a
   long-lived TCP connection.  This connection is always initiated by
   the primary server, and if the long-lived connection is lost it is
   the responsibility of the primary server to attempt to reconnect to
   the secondary server.  The detailed process used by the primary
   server when initiating a connection and by the secondary server
   when responding to a connection attempt documented in
   Section 6.1 is followed each time a connection is established,
   regardless of any previous connection between the failover
   partners.

6.1.  Creating Connections

> there is no excessive loss).

	The intent here is to keep the TCP connection unblocked, so
	that information can flow in both directions.  If one
	direction is is maxed out, it shouldn't keep information from
	flowing in the other direction.  At a TCP level it won't, but
	at an application level it will.  Much of the failover
	information flow involves one server sending a BNDUPD and then
	the partner sends a BNDREPLY.  If one server server sends more
	BNDUPD's than the other server can absorb, the TCP connection
	will block.  This will mean that any BNDREPLY's from the
	server that sent the BNDUPD's will also be blocked.  Ideally,
	the BNDUPD->BNDREPLY flow from each server to the other would
	be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is
	designed to help that be true.

	Additionally, there are messages other than BNDUPD/BNDREPLY
	(e.g. STATE, DISCONNECT, UPDDONE) that are important to
	transmit from one server to the other and not have backed up
	behind a blocked TCP connection that has been overloaded with
	BNDUPD's for the partner to process.

	We could have created a separate TCP connection for these
	control messages, but the overhead of doing that (and
	specifying that) was great enough that it seemed like using
	the application-level flow control of the
	OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff.

Thanks again for your review!

Kim

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 2 Feb 2017 18:07:56 +0100

Hi Kim,

thanks for your reply. See below.

> Am 02.02.2017 um 17:25 schrieb kkinnear <[email-masked]>:
> 
> Mirja,
> 
> Thanks for your review.
> 
Thanks, that’s great!

> 	designed to help that be true.

So you mean this is purely an application parameter saying I will not process more than X messages at once (before sending out a BNDREPLY). So this is rather independent of any socket buffer configuration, expect that the buffer needs to be large enough to at least handle X (max-size) messages which maybe is a good thing to notice as well.

However, this basically means that you at sender-side anyway need a way to cache BNDUPD message that you are not allowed to send out yet. Why don’t you just basically set this value implicitly always to 1 and say you can’t send another BNDUPD if an BNDREPLY is still outstanding…? I would guess it’s anyway rather unlikely that you need to send more than one message at once, no?

> 	OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff.

I would actually say that the overhead is rather low. Maybe one should discuss this option at least as one potential implementation possibility. The only hard requirement is that the receiver side would be able to process message coming from different connections from the same endpoint, which I assume would be easy given you anyway have to handle different connections from different endpoints, no?

Thanks!
Mirja

---

From: kkinnear <[email-masked]>
Date: Thu, 2 Feb 2017 12:43:44 -0500

Mirja,

More comments, below...

> On Feb 2, 2017, at 12:07 PM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> [... removed already handled issue -- Kim]
> 

	This is an application parameter saying that I can accept up
	to X messages at once without blocking the TCP connection.
	That isn't in conflict with what you said, but is focused a
	bit differently.  It is independent of any socket buffer
	configuration -- this is application level flow control.

> However, this basically means that you at sender-side anyway need a way to cache BNDUPD message that you are not allowed to send out yet. Why don’t you just basically set this value implicitly alwa…

	Servers frequently need send far more than one BNDUPD at once.
	The most extreme typical case is when one server is updating a
	partner which has been down with information about what has
	been happening while the partner was down.  This will generate
	thousands to tens of thousands of BNDUPD's.  When one server
	has lost its stable storage completely and needs to
	essentially be initialized by the other server, millions of
	BNDUPD's may need to flow across the link.

	Doing them one at a time, while technically correct, typically
	leaves a lot of performance on the table and could easily
	extend the time before the servers synchronize from seconds to
	tens of minutes (and possibly hours).  Many DHCP servers are
	multi-threaded and can process multiple BNDUPD's at the same
	time (though they may batch up the writes to the disk).  Thus,
	we would expect that most servers implementing this protocol
	would set this value to something substantial.

> I would actually say that the overhead is rather low. Maybe one should discuss this option at least as one potential implementation possibility. The only hard requirement is that the receiver side…

	Having different implementation possibilities in something as
	basic as connection management in a protocol already this
	complex is something we have tried hard to avoid, and we could
	only justify it if it were necessary to solve a very pressing
	problem.

Thanks -- Kim

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 27 Feb 2017 20:09:39 +0100

Hi Kim,

sorry for my late reply. Thanks for the explanation. Makes sense to me. I think slightly more explanation in the draft could be good to make clear that the TCP blocking itself is not the problem but that one kind of application layer message will block another kind which can lead to total blocking given only one TCP connection is used for all kind of message to reduce complexity in connection management. Because currently it reads a little like if there is a problem with TCP which is not really the case.

Thanks!
Mirja

> Am 02.02.2017 um 18:43 schrieb kkinnear <[email-masked]>:
> 
> Mirja,
> 
> More comments, below...
> 
>

---

From: kkinnear <[email-masked]>
Date: Mon, 27 Feb 2017 14:36:57 -0500

Mirja,

Thanks for your comment.  I will make two (identical) changes based
on your suggestion:

I will expand the first occurrence of the use of MAX_UNACKED_BNDUPD
in Section 6.1.1 "Sending a CONNECT message", from the current:

>    o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD
>       messages that this server is prepared to accept over the failover
>       connection without causing the connection to block.

to the following:

   o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD
      messages that this server is prepared to accept over the failover
      connection without causing the connection to block.  This is to
      implement application level flow control over the connection, so
      that a flood of BNDUPD messages does not cause the connection to block
      and thereby prevent other messages from being transmitted 
      over the connection and received by the failover partner.

I will also change the second place where OPTION_F_MAX_UNACKED_BNDUPD
is transmitted in Section 6.1.2 "Receiving a CONNECT message", where it
discusses creating a CONNECTREPLY message, to say the same thing (as it
currently has the same "current" text).

Thanks -- Kim

> On Feb 27, 2017, at 2:09 PM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Kim,
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 27 Feb 2017 21:43:25 +0100

Great! Thanks!

> Am 27.02.2017 um 20:36 schrieb kkinnear <[email-masked]>:
> 
> Mirja,
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Feb 2017 03:45:20 +0000

Thanks Mirja. Yours was the last pending comment. I will go ahead and approve the document.

Regards
Suresh

> On Feb 27, 2017, at 3:43 PM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Great! Thanks!
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg