Re: moving forward on draft-lear-httpbis-svcinfo-rr

My comment on those was that many of the initial SETTINGS defaults are
there for safety reasons (don't DoS servers). We'd have to sign the
records in order to allow stuff like max-concurrent-streams, otherwise
attackers can use it to increase load on servers. The advantage of
allowing these is avoiding the roundtrip to get a SETTINGS from the
server. This might allow stuff like immediately having higher
parallelism, rather than the default 100 streams.

If we stuff SETTINGS into the DNS record, we'd have to keep in mind
TTL. Either the record would need to include TTL info for the
SETTINGS, or it'd have to be coupled with the record's TTL, which I
think is probably undesirable.

On Wed, Feb 6, 2013 at 6:14 AM, Eliot Lear <lear@cisco.com> wrote:
>
> On 2/5/13 10:06 PM, Roberto Peon wrote:
>
> I don't remember BDP being one of these, though we did have discussion that
> talked about BDP in relation to some of the settings.
> These were more along the lines of max-concurrent-streams,
> max-compressor-state-size, and various other HTTP/2 specific settings that
> the client should know about/respect.
>
>
> Ok, next question: given that we're mandating a settings frame as part of
> connection initialization (at least I think we agreed on that), does putting
> this stuff in DNS save anything?
>
> Eliot
>


On Wed, Feb 6, 2013 at 6:14 AM, Eliot Lear <lear@cisco.com> wrote:
>
> On 2/5/13 10:06 PM, Roberto Peon wrote:
>
> I don't remember BDP being one of these, though we did have discussion that
> talked about BDP in relation to some of the settings.
> These were more along the lines of max-concurrent-streams,
> max-compressor-state-size, and various other HTTP/2 specific settings that
> the client should know about/respect.
>
>
> Ok, next question: given that we're mandating a settings frame as part of
> connection initialization (at least I think we agreed on that), does putting
> this stuff in DNS save anything?
>
> Eliot
>

Received on Tuesday, 5 February 2013 21:27:55 UTC