Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

[Tom Pusateri <[e-mail]>]

> On Jul 11, 2019, at 7:31 PM, Ted Lemon <[e-mail]> wrote:
> 
> On Jul 11, 2019, at 7:03 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>> The SERVER may want to conserve resources from broken clients. The RETRY DELAY is for the SERVER’s protection and it’s thoughtfully informing the CLIENT how long it has to wait before the SERVER will accept a connection from it. It doesn’t matter if the CLIENT agrees or not or whether the CLIENT follows the spec or not.
> 
> Okay, so we have the following scenarios:
> 
> 1. Server sends RETRY-DELAY, client honors it.   Result: client goes away for a long time and does polling instead of push.  Behavior on client is not great, but probably won’t be noticed by a typical end-user other than as an inexplicable inconvenience.   Vendor will have no strong motivation to fix.
> 2. Server sends RETRY-DELAY, client ignores it.  Result: whatever broken behavior the client exhibits, up to and including back-to-back reconnects.  UX may degrade substantially: in particular, this will affect battery life for mobile devices.  Practically speaking, in this case the vendor will be motivated to fix.
> 3. Server sends RST.   Result: same as 2.
> 
> So the question is, do we want outcome (1) or outcome (2)?
> 


There is no back to back reconnect in the #2 case. The server shouldn’t accept the connection after sending a RETRY DELAY to this client. The client may ignore the RETRY DELAY but this doesn’t matter. It’s only a courtesy that the SERVER tells the client how long it has to wait.

So #1 and #2 are the same.

The server gets abused if it does #3. It should always send the RETRY DELAY to protect itself.

Tom