Re: Proposal: Run QUIC over DTLS

[Ted Hardie <[e-mail]>]

On Tue, Mar 13, 2018 at 3:50 PM, Eric Rescorla <[e-mail]> wrote:

>
> On Tue, Mar 13, 2018 at 12:20 PM, Ted Hardie <[e-mail]> wrote:
>
>> On Tue, Mar 13, 2018 at 9:52 AM, Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>> I'd like to focus on the architectural question for the moment. I
>>> think there's broad -- though not universal -- agreement that the
>>> stream 0 thing is not great, but a fair amount of debate about
>>> what the right architecture and architectural principles are.
>>> It's not really productive to talk about schedule impact until
>>> we understand what the right thing is.
>>>
>>>
>> Hi Eric,
>>
>> As it stands, you've identified a pain point, and you've made a proposal
>> to  rebase a key part of the architecture on the basis of that pain.
>>
>> Folks agree with you that it is a pain point, but all of the feedback
>> you're getting that this isn't worth the schedule slip is, fundamentally,
>> also feedback on how bad the pain is.  The message I read (and, to be fair,
>> participated in sending) from this thread is "not bad enough for this".
>> It's clearly bad enough that Christian, I, and I'm sure others would like
>> you to create a PR to incorporate what improvements from your proposal can
>> fit into the current structure.   If that's the conversation you want to
>> have, I'm happy to jump in.
>>
>
> Hi Ted,
>
> I appreciate your concern with the schedule, and I do recognize that
> there are people who think that this is too late to discuss, but I
> also heard people who thought it was worth exploring, which is what
> I'm asking for at the moment.
>
> Even if I were to concede that that were not the case -- which I don't
> -- it's not possible to have a discussion about what we can do to
> address these issues without understanding the architectural
> principles we are trying to follow, which requires actually discussing
> the points I raised above.
>
> Hi Ekr,

It appears that I wasn't clear; sorry.  I am fine with continuing to
discuss the architectural points, but I don't want to do so by putting
aside discussion of the schedule.  Your note said that you felt it wasn't
productive to discuss the schedule impact while discussing the
architectural issues, and it was that point I disagree with it.

As I said earlier on, I don't want QUIC to be the last turn of the crank
for producing new transport protocols, and determining what lessons we
ought to learn for the next turn is always valuable, even if we choose to
make more modest changes in this effort.

I hope this clarifies my intent,

regards,

Ted



> -Ekr
>
>
>
>> But I don't think we can ignore the signal that the current state of
>> affairs actually works and that changing away from it so completely isn't
>> worth the (new) pain.  I think we will lose both momentum and expertise if
>> we start over to this extent at this juncture, and I'd rather we did not.
>> I'm particularly worried that the uncertainty around this could kill the
>> productivity of the hackathon and London meeting, and that we won't recover
>> until the next interim, if then.
>>
>> Not talking about that as we analyze this seems to me to be the wrong
>> choice.
>>
>> regards,
>>
>> Ted
>> /no hats
>>
>>
>>
>