Change:
WHIP client SHOULD send a single aggregated HTTP PATCH request with all the ICE candidates it has buffered so far. <ins> In case of unstable network conditions, the ICE restart HTTP PATCH requests and responses might be received out of order.  In order to mitigate this scenario, when the client performs an ICE restart, it MUST discard any previous ice username/pwd frags and ignore any further HTTP PATCH response received from a pending HTTP PATCH request and apply only the ICE information received in the response to the last sent request.  If there is a mismatch between the ICE information at the client and at the server (because of an out of order request), the STUN requests will contain invalid ICE info and will be rejected by the server.  When this situation is detected by the WHIP Client it SHOULD send a new ICE restart request to the server. </ins> 4.2. In order to reduce the complexity of implementing WHIP in both

Discussion:
If you have more than one ice-restart PATCH request in flight at once, it'll be unclear to the server which one was sent first. This ambiguity is bad; it won't be clear which selected ICE candidate pair to switch to. One simple solution would simply be to forbid this, but Sergio pointed out at the meeting that this might be problematic if your device fell off its network (because it might not get the response to the first ice-restart, so would have to wait for it to time out). If so we need another way to resolve the ambiguity.
Would sending a header (rfc7232) on the response help solving the issue?
I'm not adept enough with HTTP semantics to be certain, but it seems like it could? It'd mean servers are required to respond to at most once ICE restart per second. That adds some implementation complexity, but doesn't seem like an enormous limitation.
Right, the timestamp has only second accuracy, so it would not work if both patch requests have been received in the same second. This is however kind of an edge case in an edge case. Could we just state that if both ice restarts are received with same the client should send a new ice restart request? All the other alternatives seems uglier and more complex.
Basing it on "if two were received" doesn't let the server know which one the client is using, in the case where one of the responses wasn't received (because the whole mess was triggered by a network failure). However, in that case one of the ICE handshakes won't succeed, so the server can just continue with the (hopefully) succeeding one. I agree this is an edge case of an edge case.
I think I have worded my comment badly. Let's back and see which would be the problematic case. The client will update its ICE username fragment and pwd before sending the PATH request and the server will restart ice when receiving a new PATCH request with an updated ice username fragment/pwd. I don't think that there is any issue at all if any of the requests or responses are not received by either side. The issue happens when client has sent two PATCH requests (first with username client1 and second with client2) and the server receives them out of order and generates two responses one with server 1 and the later with server 2.

So the client would be using client2:server1 and the server server2:client1. The header would allow us to know (up to a 1s of resolution) which request has been processed first by the server, but would not allow us to solve the problem, and the client would have to send a new Ice restart request in order to get to a good state. The other alternative is always send an with the last know etag, that would prevent the server for processing out of order ice restart request, but it would prevent the ice restart from working if the previous response was lost and we don't know the value of the actual server etag.
Let us please not use in new protocols. It causes a number of complications which implementers are likely to get wrong (dealing with sub-second transactions, interaction with , etc.). Let's please stick to ETags only.
Thinking about this further, both and have the wrong semantic. The semantic we need is that we need the client to define an order to ICE restarts, and then the server should reject or ignore ICE restart requests that arrive out of order. (This is the semantic that SIP achieves with .) One possibility would be to use the header for this, but I don't know how appropriate that would be, or if it fits the semantic for that header. (This would still have the at-most-one-per-second problem, but in principle the client could "cheat" by bumping the seconds field on subsequent requests, so long as there wasn't a steady state of more than one ICE restart per second.). Pinging NAME [does that work?] as the author of URL Are there any better HTTP client headers for this purpose? Is this a terrible idea?
Just thinking aloud... Send PATCH with If-Match. If you get 412, resynchronise using HEAD and try again?
If-Match with which ETag? Remember the worrying case is where you send the second request before the response to the first request has arrived. (And yes, if interfaces are flapping, it's possible for it to turn out that there are to be three (or more) outstanding requests...)
The last one the client got. If it's obsolete (which is likely after a failrure), client gets 412, gets the last ETag using HEAD, then resends with the right ETag.

That means (at least) 3 RTTs to recover from a network failure, which isn't great, but I agree it's probably the easiest solution protocol-wise. A double ICE restart like this should hopefully be a pretty rare phenomenon.
NAME Agreed on both counts.
How about not making the protocol harder and let the client deal with it by sending a new ICE restart in case there are receive an out of order response and ICE is not in state?
NAME NAME what do you think about my previous comment?
NAME The problem is that receiving a response out of order doesn't necessarily mean that that request was processed out of order, and vice-versa. Also, the out-of-order response might not be received, because this will be happening at times of network flakiness. I like NAME suggestion, but it would mean defining HEAD (and thus presumably GET) on the WHIP resource URL in order to get resync working, which isn't great.
I have re-read my previous comment, and it does not make any sense in fact. Let me try again to rephrase my thoughts. The server response order is irrelevant. When the client performs an ICE restart, it discards the ice username/pwd frags, so if there was a previous request pending to receive an answer it must be discarded. So only the response to the last sent request is relevant to the client. So the key question is detecting out of order request at the server. Instead of trying to resolve it at HTTP level, we could just apply the ICE info received by the server and wait for the ICE connection states. If there is a mismatch between the information at the client and at the server (because an out of order request), the STUN request will contain an invalid ICE info and will be rejected by the server. In terms of webrtc w3c apis, this would trigger an ice or which would be an indication for the client to perform a new ICE restart. Depending on the local candidates, it may require the ice request to timeout (30s?) but it would be the client would eventually recover. The client could also optimize this by adding a timeout to receive the state to start a new ice restart (as already done by many non trickle ice services to not have to wait for candidates in private networks).

So you're arguing that we make the ICE restart best-effort, and rely on the application to trigger a new restart in the rare case when the previous restart failed. That makes a lot of sense. However, I'm a little concerned this will cause unacceptable latency (see RFC 8863).
We are talking about an edge case of an edge case on unstable networks.. best effort is more than enough IMHO.. the alternative is complicating a lot the protocol..
I reluctantly agree. I still think the failure should be signalled explicitly at the HTTP layer, at the very least it will make troubleshooting easier.
NAME NAME wdyt?
Why not require that the server indicate the mismatch to the client, e.g. with HTTP 409?
because the server has no way of detecting the out of order requests El vie, 13 may 2022 14:29, Juliusz Chroboczek NAME escribió:
I'll switch my brain on next time. Sorry.
NAME NAME any feedback on this? I would love to update the draft asap and to a WGLC on it..
I feel we should go into LC with the issue open.
It sounds like I'm in the rough on making the protocol more complex, so if you want to write up your solution as a PR I'm willing to review it to make sure it makes sense.
NAME the PR is in here: URL