Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5E712965D for ; Thu, 16 Mar 2017 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIjeisN6uz9x for ; Thu, 16 Mar 2017 09:05:26 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3801812968F for ; Thu, 16 Mar 2017 09:05:24 -0700 (PDT) Date: Thu, 16 Mar 2017 09:05:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1489680323; bh=0AZZkmqVJwfhm3qLgxaNyoboJmgts2LuG/KU7yjYI9I=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SCu5GTw99j4rxsZvHSwaUFy+nblaWxp84UpLI/qNywYC1wywki4BXwFPAqDAV1UQW Kd+S/dPSp4Kt21LKImvUMnl+mxhaBKrnrdnaSHHxGu7S8kDjSBTrojevuGGkw4xcF6 kyA9jhS5iTHDk/K5B/NC6gxnBpWpDIy+jrG2yKE8= From: hardie Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Flow/congestion control and rejected 0-RTT (#390) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58cab7c3376d9_1a53fd6f0cb5c30106190"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: hardie X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:05:28 -0000 ----==_mimepart_58cab7c3376d9_1a53fd6f0cb5c30106190 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2017 at 10:11 PM, Martin Thomson wrote: > Yes, this all binds to the 0-RTT credentials, so that places an upper > bound on how long this is valid for. > > I'm going to concede straight up that the lifetime of things like "how > much memory I am going to commit" is 100% not the same as the credentia= l > lifetime. But the client doesn't have anything else to go on. > I agree that it doesn't have anything else to go on now. We could, in theory, create methods to give it more to go on (e.g. a separate transpor= t parameter lifetime provided by the server), but I seriously doubt that's worth it. That assessment makes me wonder, though, how the success rate of the 0RTT= connections with defaults will compare with that of connections using remembered parameters. If the remembered parameter connections succeed a= s often or more often, then they are clearly double plus good; if they succeed less often, then the delta is the trade-off. I don't, unfortunately, have any data on what the delta is going to be in differen= t network conditions, and I distrust my own instincts here (I fear, but without data, that they will fail more often in the cases where the failures hurt worst). > Ultimately, when the new session is created with a 0-RTT offer, the ser= ver > can always choose to reject 0-RTT if it can't live up to that promise. > That's all it has, and we can ever hope for. > Well, that and clear signaling that this was why it was closed. > Given the dynamics involved, this is going to be a per-connection decis= ion. > > Sure, that means that you have a bunch of pressures that eventually end= up > with a flat success/fail decision, and you might be sad about that, but= I'm > far more sad about the current design lacking any real control or > determinism. At least this way the server can tune in the values it > provides so that it gets the best result (for whatever metrics the serv= er > cares about). > I think the control surface is very hard to use. You can't the credentia= l life time, so you can provide a value that is "generally useful", but no more. That may be better than nothing, but I don't think it stands much tuning. Ted > =E2=80=94 > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . > -- = You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/issues/390#issuecomment-287105968= ----==_mimepart_58cab7c3376d9_1a53fd6f0cb5c30106190 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2017 at 10:11 PM, Martin Thomson <notifications@github= .com>
wrote:

> Yes, this all binds to the 0-RTT credentials, so that places an uppe= r
> bound on how long this is valid for.
>
> I'm going to concede straight up that the lifetime of things lik= e "how
> much memory I am going to commit" is 100% not the same as the c= redential
> lifetime. But the client doesn't have anything else to go on. >
I agree that it doesn't have anything else to go on now. We could, i= n
theory, create methods to give it more to go on (e.g. a separate transpor= t
parameter lifetime provided by the server), but I seriously doubt that= 9;s
worth it.

That assessment makes me wonder, though, how the success rate of the 0RTT=
connections with defaults will compare with that of connections using
= remembered parameters. If the remembered parameter connections succeed a= s
often or more often, then they are clearly double plus good; if they
succeed less often, then the delta is the trade-off. I don't,
unfortunately, have any data on what the delta is going to be in differen= t
network conditions, and I distrust my own instincts here (I fear, but
= without data, that they will fail more often in the cases where the
failures hurt worst).

> Ultimately, when the new session is created with a 0-RTT offer, the = server
> can always choose to reject 0-RTT if it can't live up to that pr= omise.
> That's all it has, and we can ever hope for.
>
Well, that and clear signaling that this was why it was closed.

> Given the dynamics involved, this is going to be a per-connection de= cision.
>
> Sure, that means that you have a bunch of pressures that eventually = end up
> with a flat success/fail decision, and you might be sad about that, = but I'm
> far more sad about the current design lacking any real control or > determinism. At least this way the server can tune in the values it<= br> > provides so that it gets the best result (for whatever metrics the s= erver
> cares about).
>
I think the control surface is very hard to use. You can't the crede= ntial
life time, so you can provide a value that is "generally useful"= ;, but no
more. That may be better than nothing, but I don't think it stands m= uch
tuning.

Ted



> =E2=80=94
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/390#issuecomment-28= 6959699>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5L-bGcJigm= RvTLi3NnNJIsry30AEks5rmMRqgaJpZM4MavGm>
> .
>

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, = or mute the thread.=3D""

= ----==_mimepart_58cab7c3376d9_1a53fd6f0cb5c30106190--