Re: [Wish] Use entity-tags for solving out of order PATCH requests

Juliusz Chroboczek <jch@irif.fr> Wed, 02 March 2022 20:38 UTC

Return-Path: <jch@irif.fr>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD753A0C85 for <wish@ietfa.amsl.com>; Wed, 2 Mar 2022 12:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 bCVdnwijzqbr for <wish@ietfa.amsl.com>; Wed, 2 Mar 2022 12:38:02 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C163A0C41 for <wish@ietf.org>; Wed, 2 Mar 2022 12:38:00 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 222KbvEQ009072; Wed, 2 Mar 2022 21:37:57 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 190BC115281; Wed, 2 Mar 2022 21:37:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id mkGDJFUZOBqS; Wed, 2 Mar 2022 21:37:55 +0100 (CET)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 20A5E11527F; Wed, 2 Mar 2022 21:37:55 +0100 (CET)
Date: Wed, 02 Mar 2022 21:37:55 +0100
Message-ID: <87fso0ay58.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Lorenzo Miniero <lorenzo@meetecho.com>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, WISH List <wish@ietf.org>
In-Reply-To: <20220302182443.0b20caa6@lminiero>
References: <CA+ag07bXRH9en5rWg3FBXOFp4OCz1N5HtpyK6+nbjycj1jkTaA@mail.gmail.com> <20220302182443.0b20caa6@lminiero>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 02 Mar 2022 21:37:57 +0100 (CET)
X-Miltered: at korolev with ID 621FD5A5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 621FD5A5.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 621FD5A5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/o4a06kqxg8y6Tshltld_NYsWVp0>
Subject: Re: [Wish] Use entity-tags for solving out of order PATCH requests
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2022 20:38:06 -0000

>> I have prepared a PR for the draft to address the issue of how to
>> protect WHIP against out of order PATCH requests based on the
>> entity-tags as discussed at the latest IETF meeting.

Does that mean that we're now serialising trickle?

Suppose the exchange goes:

  C->S: POST Offer
  S->C: 202 Answer
  C->S: PATCH candidate
  
Now suppose that the client generates a new ICE candidate before it
receives the answer to its latest PATCH request.  Since it doesn't know
the reply's ETag yet, it must buffer the new candidate until it receives
the response, right?

Hopefully I'm misunderstanding something, since serialising trickle
needlessly complicates the implementation of clients.  If I'm not, then
I have no strong objection to requiring this serialisation, but if that's
what you're requiring, it must be made explicit in the draft -- you must
say explicitly that it's not allowed to have multiple candidates in flight.

-- Juliusz