- From: Benjamin Kaduk <bkaduk@akamai.com>
- Date: Thu, 27 Jul 2017 13:18:50 -0500
- To: Willy Tarreau <w@1wt.eu>, Martin Thomson <martin.thomson@gmail.com>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <0f8ca6b2-d7d5-d40b-e54b-f4872055af8c@akamai.com>
On 07/25/2017 10:44 PM, Willy Tarreau wrote: > So while we designed the 4NN principle as an end-to-end invitation to > retry, offering the guarantee that the request was not processed and > that it will not be replayed, this same signaling is perfectly usable > between components. The fact that the client isn't notified of the > intermediary retrying it is not a problem because if the client has > sent its request in 0-RTT and has sent its ClientFinished, it's because > it expected it to be completed. By the way that was the recommended way > to implement 0-RTT before we discussed this at the workshop ;-) I just want to point out that 4NN was not a *guarantee* that the request will not be replayed until https://github.com/martinthomson/http-replay/pull/25 added text that the server MUST consistently use the same approach, if I understand things correctly. That is, draft-thomson-http-replay-00 leaves open the possibility for one server in a cluster to return 4NN and another server in that cluster to have a different level of load (or whatever) and successfully process the request. > However, I'm not willing to open the draft to let intermediaries retry > in the general case, at least for the reasons Ben mentionned and because > for me there is a difference between the specific model above where we > consider the intermediary as part of the server system and many other > models. I'd rather not see blackboxes decide to do whatever on the > client's behalf as a way to "accelerate" networks... > > But I think that by using a careful wording we can ensure that implementers > who consider themselves as part of the server system see what to do in their > situation. We can possibly put a few MUST NOT rules for specific cases which > risk to become border-line. > I agree with Martin that this is pretty convincing, and hope we can come up with appropriately flexible language that maintains the other properties we're looking for. -Ben
Received on Thursday, 27 July 2017 18:19:49 UTC