Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Tue, Jul 31, 2018 at 8:21 PM, Ted Lemon <[e-mail]> wrote:

>
> Sorry, has this been changed in a new version?
>>
>
> The text you commented on is the new version, with some additional text to
> address a point raised in the gen-art review.   We gamed this out pretty
> thoroughly—I don't think there's an actual problem here, although I
> understand why it looks that way.   The worst case scenario here is that a
> middlebox breaks the session signaling, which just looks like "the server
> doesn't support session signaling," which is fine.
>

I think I'm just confused about the meaning of this text. Is it an analysis
or a recommendation?



>
>>
>>> S 5.4.
>>>> >         generate a response, the application-layer software informs
>>>> the
>>>> >         TCP implementation that it should go ahead and send the TCP
>>>> ACK
>>>> >         and window update immediately, without waiting for the
>>>> Delayed ACK
>>>> >         timer.  Unfortunately it is not known at this time which (if
>>>> any)
>>>> >         of the widely-available networking APIs currently include this
>>>> >         capability.
>>>>
>>>> Are you going to make a recommendation here?
>>>>
>>>
>>> Out of scope for DNSOP to update TCP stack APIs.
>>>
>>
>> Sorry, it wasn't clear from context what I was referring to here. You
>> discuss a number
>> of strategies and then say they are all bad. Do you had a recommendation
>> for what
>> people ought to do?
>>
>
> We don't.   This is text that was heavily touched by Mirja's DISCUSS, so I
> suspect that by the time Stuart is done addressing her DISCUSS, this will
> have been fixed.   However, I will try to remember to check just to be
> sure. :)
>

OK.


S 6.6.1.2.
>>>> >      client a Retry Delay message, or by forcibly aborting the
>>>> underlying
>>>> >      transport connection) the client SHOULD try to reconnect, to that
>>>> >      service instance, or to another suitable service instance, if
>>>> more
>>>> >      than one is available.  If reconnecting to the same service
>>>> instance,
>>>> >      the client MUST respect the indicated delay, if available, before
>>>> >      attempting to reconnect.
>>>>
>>>> Do you want to recommend some sort of randomness around this value to
>>>> avoid avalanche?
>>>>
>>>
>>> The server is specifying the retry delay, so if the client adds
>>> randomness, that could result in more collisions rather than fewer.
>>>
>>
>> Sure, if the server actually randomizes it itself. Perhaps that's worth
>> recommending?
>>
>
> Yeah, I was dragging my feet on this, but inclined the same way.
>
> diff --git a/draft-ietf-dnsop-session-signal.md
> b/draft-ietf-dnsop-session-signal.md
> index a9037e0..85bc28d 100644
> --- a/draft-ietf-dnsop-session-signal.md
> +++ b/draft-ietf-dnsop-session-signal.md
> @@ -1463,6 +1463,12 @@ are described in {{delay}}.
>  After sending a Retry Delay message,
>  the server MUST NOT send any further messages on that DSO Session.
>
> +The server MAY randomize retry delays in situations where many retry
> delays are sent
> +in quick succession, so as to avoid all the clients attempting to
> reconnect at once.
> +In general, implementations should avoid using the Retry Delay message in
> a way that
> +would result in many clients reconnecting at the same time, if every
> client attempts
> +to reconnect at the exact time specified.
> +
>  Upon receipt of a Retry Delay message from the server,
>  the client MUST make note of the reconnect delay for this server,
>  and then immediately close the connection gracefully.
> @@ -1520,7 +1526,9 @@ or by forcibly aborting the underlying transport
> connection)
>  the client SHOULD try to reconnect,
>  to that service instance, or to another suitable service instance, if
> more than one is available.
>  If reconnecting to the same service instance, the client MUST respect the
> indicated delay,
> -if available, before attempting to reconnect.
> +if available, before attempting to reconnect.   Clients should not
> attempt to randomize the delay;
> +the server will randomly jitter the retry delay values it sends to client
> if this behavior is
> +desired.
>

LGTM.



>  If the service instance will only be out of service for a short
> maintenance period,
>  it should use a value a little longer that the expected maintenance
> window.
>
>
>> Mostly I just missed this. With that said, generally we are discouraging
>> compression in cryptographic protocols.
>> OTOH, I'm not that worried about the covert-channel either, so it's kind
>> of a tossup
>>
>
> OK.   I'm going to call it done then, at least until we hear back from
> Stuart and Mirja.
>

WFM.