Subject: [DNSOP] AD review of draft-ietf-dnsop-session-signal

From: Warren Kumari <[email-masked]>
Date: Sat, 2 Jun 2018 11:08:38 -0400

Hi there,

Thank you for writing this document, I found it clear and well written.

I do have a few comments that I’d like addressed before I start IETF LC —
addressing these now will avoid issues later in the process.
The majority of these are nits, but one is more of a (very easily
addressed) substantive / editorial / process issue.

Firstly the "substantive" issue:
Throughout the document you say things like:
"This document defines a new DNS OPCODE, DSO (tentatively 6),..."

Can you please go through and change this to something like ([TBA1],
tentatively
6)?
I realize that that isn't quite as readable for "normal" reading, but this
is sufficiently close to the end of the process that the IANA will read it
soon and I don't want any occurrences to be missed. An exmaple of where
this could have been an issue is in the table on page 16. If some number
other than 11 were assigned for DSOTYPENI it might not get caught here.
Sorry for the process wonkery.

Nits / questions:
Section 3.  Terminology
1: "The term has no relationship to the "session layer" of the OSI
"seven-layer model" popularized in the 1980s."
 -- I don't really get the purpose of the phrase "popularized in the
1980s." - it feels like it breaks the flow and feels like it will simply
distract people into side arguments about if it was the 80's or 90's when
this was "popularized". Note that this is truly a minor nit.

Section 3.  Terminology
2: "This document uses the term "same server instance" as follows:
o  In cases where a server is specified or configured using an IP
address and TCP port number, two different configurations are
referring to the same server instance if they contain the same IP
address and TCP port number."

Because you opened this Pandora's box -- in many Anycast deployments this
isn't really true -- if you make a TCP connection to linkedin.com on port
80 (or 8.8.8.8 on 53) you are likely to hit the same "server instance" for
a while, but at some point routing will change and you may hit some
completely other location (and server). In many cases this will be sticky
over long timeframes (a good slidedeck is the
https://www.slideshare.net/shawnzandi/how-linkedin-used-tcp-anycast-to-make-the-site-faster
). Anyway, since you mention IP:PORT-> "same server instance" you might
want to toss in some weasel words that the protocol does deal with this
case (by falling over and reconnecting).

"The term "long-lived operations" refers to operations such as Push
Notification subscriptions [I-D.ietf-dnssd-push], Discovery Relay
interface subscriptions [I-D.ietf-dnssd-mdns-relay], and other future
long-lived DNS operations that choose to use DSO as their basis, that
establish state that persists beyond the lifetime of a traditional
brief request/response transaction."
This sentence is somewhat hard to read - I *think* the repeated use of
"that" in "... that choose to use DSO as their basis, that establish.." is
part of the issue. Not sure if it can be simplified?

"Section 5.1.3.  Middlebox Considerations"
The second paragraph of this section makes me slightly uncomfortable. I
understand why it is here, but the tone of it sounds supportive of
DSO-aware middleboxes being created. This might just be my personal bias
(and so feel free to ignore it), but I'd think that on the whole we'd
prefer that middleboxes don't monkey with DSO traffic. If they *do*,
definitely there should be advice on how not to get it wrong, but the tone
of this sounds more supportive / permissive than I (personally) would have
expected.

Section 5.2.2.  DSO Data
"Similarly, after an mDNS Relay client..."
I think that this is the first use of mDNS - please expand the acronym.

Section 5.4.  DSO Response Generation
"Possible mitigations for this problem include:..."
This doesn't mention the mitigation of "just padding the packet until it is
a full sized segment". While anti-social, it is a mitigation (trading
increased bandwidth for performance).

Having now finished writing these up, I realize that while I'd *prefer* a
new version before starting IETF LC, I'm also fine with kicking it off with
the current text and the (minor) fixes can be addressed after IETF LC /
with the RFC Ed.

Please let me know how you'd like to proceed.
W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 2 Jun 2018 15:13:25 -0400

I made all of these suggested changes on github except for the Section 3 “same server instance” pandora’s box.

The authors can discuss how they want to change this one or leave it for later.

If I don’t hear anything in a day or two, I’ll push out another version.

Thanks,
Tom

> On Jun 2, 2018, at 11:08 AM, Warren Kumari <[email-masked]> wrote:
> 
> Hi there,
> 
> I do have a few comments that I’d like addressed before I start IETF LC — addressing these now will avoid issues later in the process.
> The majority of these are nits, but one is more of a (very easily addressed) substantive / editorial / process issue.
> 
> Can you please go through and change this to something like ([TBA1], tentatively 6)?
> I realize that that isn't quite as readable for "normal" reading, but this is sufficiently close to the end of the process that the IANA will read it soon and I don't want any occurrences to be missed. An exmaple of where this could have been an issue is in the table on page 16. If some number other than 11 were assigned for DSOTYPENI it might not get caught here.
> 1: "The term has no relationship to the "session layer" of the OSI "seven-layer model" popularized in the 1980s."
>  -- I don't really get the purpose of the phrase "popularized in the 1980s." - it feels like it breaks the flow and feels like it will simply distract people into side arguments about if it was the 80's or 90's when this was "popularized". Note that this is truly a minor nit.
> 
> Section 3.  Terminology
> Because you opened this Pandora's box -- in many Anycast deployments this isn't really true -- if you make a TCP connection to linkedin.com <http://linkedin.com/> on port 80 (or 8.8.8.8 on 53) you are likely to hit the same "server instance" for a while, but at some point routing will change and you may hit some completely other location (and server). In many cases this will be sticky over long timeframes (a good slidedeck is the https://www.slideshare.net/shawnzandi/how-linkedin-used-tcp-anycast-to-make-the-site-faster <https://www.slideshare.net/shawnzandi/how-linkedin-used-tcp-anycast-to-make-the-site-faster> ). Anyway, since you mention IP:PORT-> "same server instance" you might want to toss in some weasel words that the protocol does deal with this case (by falling over and reconnecting).
> 
> This sentence is somewhat hard to read - I *think* the repeated use of "that" in "... that choose to use DSO as their basis, that establish.." is part of the issue. Not sure if it can be simplified?
> 
> 
> The second paragraph of this section makes me slightly uncomfortable. I understand why it is here, but the tone of it sounds supportive of DSO-aware middleboxes being created. This might just be my personal bias (and so feel free to ignore it), but I'd think that on the whole we'd prefer that middleboxes don't monkey with DSO traffic. If they *do*, definitely there should be advice on how not to get it wrong, but the tone of this sounds more supportive / permissive than I (personally) would have expected.
> 
> Section 5.2.2.  DSO Data
> This doesn't mention the mitigation of "just padding the packet until it is a full sized segment". While anti-social, it is a mitigation (trading increased bandwidth for performance).
> 
> 
> Having now finished writing these up, I realize that while I'd *prefer* a new version before starting IETF LC, I'm also fine with kicking it off with the current text and the (minor) fixes can be addressed after IETF LC / with the RFC Ed.
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Jun 2018 12:37:45 -0700

> The authors can discuss how they want to change this one or leave it for later.

I would just suggest that we add:

When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent.   If a change in network topology causes packets in a particular TCP connection to be sent to an anycast server instance that does not know about the connection, the normal keepalive and TCP connection timeout process will allow for recovery.   If after the connection is reestablished, the client's assumption that it is connected to the same service is violated in some way, that would be considered to be incorrect behavior in this context.   It is however out of the possible scope for this specification to make specific recommendations in this regard; that would be up to follow-on documents that describe specific uses of DNS stateful operations.

I would suggest also that instead of "server instance" we say "service instance," to avoid creating confusion between a service and a physical device that provides that service, of which there could potentially be many answering to a single IP address.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 2 Jun 2018 16:45:24 -0400

That works for me...

W

On Sat, Jun 2, 2018 at 3:37 PM Ted Lemon <[email-masked]> wrote:

> When an anycast service is configured on a particular IP address and port,
> it must be the case that although there is more than one physical server
> responding on that IP address, each such server can be treated as
> equivalent.   If a change in network topology causes packets in a
> particular TCP connection to be sent to an anycast server instance that
> does not know about the connection, the normal keepalive and TCP connection
> timeout process will allow for recovery.   If after the connection is
> reestablished, the client's assumption that it is connected to the same
> service is violated in some way, that would be considered to be incorrect
> behavior in this context.   It is however out of the possible scope for
> this specification to make specific recommendations in this regard; that
> would be up to follow-on documents that describe specific uses of DNS
> stateful operations.
>
> I would suggest also that instead of "server instance" we say "service
> instance," to avoid creating confusion between a service and a physical
> device that provides that service, of which there could potentially be many
> answering to a single IP address.
>
> --