On Tue, Jul 31, 2018 at 8:21 PM, Ted Lemon <mel...@fugue.com> 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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
