[Wish] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-wish-whip-14: (with DISCUSS and COMMENT)

Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> Thu, 23 May 2024 14:36 UTC

Return-Path: <zahed.sarker.ietf@gmail.com>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2AB15C1C3D7A; Thu, 23 May 2024 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FYwGJYmovi5T; Thu, 23 May 2024 07:36:39 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D13BC1B1623; Thu, 23 May 2024 07:36:39 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2bdd9f04045so726149a91.0; Thu, 23 May 2024 07:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716474999; x=1717079799; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RU/XppA7egw9r8YhDmrp+4GzswcSubX8AunSUUIUd3Y=; b=KIVl+w+jkJFZy2Lqgx2cw6429e/gR6aY59SX2rtCNEfZMTSYGUTfx42WdPHiv+uuQB JNRyhx6dhmmctYo/uJEzUz00e3Quhkb0kKzqLq46LBOWsqapyNYoW73MMs5ys4HQ8Mcm /lb4RS/iUYQyOUrp+MX+RBhUX2KAZhnGY9DjAFVtWUyBWlEK10WNIsGkhwWiy9s8/sjZ YY/jN70SgOkbFNuJ/Nmm4q1nU9Al0Pk4wgoMO/7tSsMANM3jJDuIqGGYvZ6L+c24YE3w 6bX9EVeMpxaeJuGLHwEmWWRCalCRhMH+XeoJmBcxzrYNI1C8DHxrmq1zWnGwGNj8Iy7n CJxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716474999; x=1717079799; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RU/XppA7egw9r8YhDmrp+4GzswcSubX8AunSUUIUd3Y=; b=Z2cpLkEcETfBus6zcEQuEEvf/SkV7VuPaVNHsSPq+8jxRX2zJCGIKgvLZIHXOERGNO Rx3MiPSryAytQ7s2YNG+oO9aEvB/uFia61jK/8ULTae1NvRFPlDfOYIo4slt0o9HDotZ AdCykvSrFfSKvtAlrb22JuUjllO87ev1exPM+0w5MfaeeNv4fIxdqb0KVcAoX1mA0wRt +3Z4xjxQuO3mcrpmp117yzuWSvWvsKztQ7vr1bpCTj8Dknl9CtA4hYKTxlasERDtNeWA TX6ICcMurDEK8DEQeKUBZcGDX9KRTAA43mBxGyMH2coSskOTNhN+1ODSOkbculmle+D9 yjPA==
X-Forwarded-Encrypted: i=1; AJvYcCXQLYLJI7eLDMo0J+DBIMa8zFASOYF039zajY8+Dy2zMkPn96rXSQoW7Cp8VcGxPibypTO7PqO5LCVMRooaamNBXaGzwtR0uspyOQ9dPkwW7CzmaAUX0vnZQvwmyqzxTTuOzNutsJzFtUL1lFujhv7tBbQ=
X-Gm-Message-State: AOJu0YzCKnV4eeCETrHFSiJceIyH+Sayc52UUnutExjmzzcCO1/v2+qX iGKo8QN4TgX+Z+hdSsmweLZE8rlhUeLrOU7gZknpEWZm02xosOz1u3rSwbEOPvermLue7HWwEJ7 bOLZz+OVW/z2YByu8GmUT7Svi/cE=
X-Google-Smtp-Source: AGHT+IEcgiXP63C2w1EHhK912OKy5cnLnfrK/cd8DI9CDK7Ga3LV3mmrtDk9Jpff4EOAhRk6ddAzg3MJ/t9Zq749qH0=
X-Received: by 2002:a17:90a:2f61:b0:2b6:214a:71ac with SMTP id 98e67ed59e1d1-2bddce5c5a6mr3596012a91.3.1716474998496; Thu, 23 May 2024 07:36:38 -0700 (PDT)
MIME-Version: 1.0
References: <171586754640.59774.15879178886991726753@ietfa.amsl.com> <CA+ag07a_rKDYqRzqn9F9epq5wt5-a+igpThiVj0gsTCSJi-Cuw@mail.gmail.com> <CAEh=tccYvE1c2GJr_q9S04nCL=gE4wLiNKmw75sStksThOHE4w@mail.gmail.com> <CA+ag07b7qq8nx10xO=QPU+ofVmnYJe+VBMgfwcS4LPETjGp=FQ@mail.gmail.com>
In-Reply-To: <CA+ag07b7qq8nx10xO=QPU+ofVmnYJe+VBMgfwcS4LPETjGp=FQ@mail.gmail.com>
From: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Date: Thu, 23 May 2024 16:36:26 +0200
Message-ID: <CAEh=tcfOcNqk4khVz7wj-cxqEzyE6vznkovHZKHCp6k83HT74g@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008d279c06191ffa51"
X-MailFrom: zahed.sarker.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, draft-ietf-wish-whip@ietf.org, wish-chairs@ietf.org, wish@ietf.org, nils.ohlmeier@8x8.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Wish] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-wish-whip-14: (with DISCUSS and COMMENT)
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Owner: <mailto:wish-owner@ietf.org>
List-Post: <mailto:wish@ietf.org>
List-Subscribe: <mailto:wish-join@ietf.org>
List-Unsubscribe: <mailto:wish-leave@ietf.org>

On Thu, May 23, 2024 at 1:42 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On Thu, May 23, 2024 at 11:50 AM Zaheduzzaman Sarker <
> zahed.sarker.ietf@gmail.com> wrote:
>> On Mon, May 20, 2024 at 4:02 PM Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>> Hi Zahed, thank you very much for your review and comments, please check
>>> inline
>>> On Thu, May 16, 2024 at 3:52 PM Zaheduzzaman Sarker via Datatracker <
>>> noreply@ietf.org> wrote:
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> Thanks for working on this specification. Thanks to Bernard Aboba for
>>>> his
>>>> TSVART review.
>>>> I would like to discuss two points -
>>>> 1. Rate adaption considerations when using WebRTC for ingest: as
>>>> pointed out by
>>>> the TSVART reviewer, the existing congestion control used in the WebRTC
>>>> libraries is not suitable for streaming, hence, need special
>>>> considerations to
>>>> be used as it is. I was expecting at least some considerations or
>>>> warnings in
>>>> the section 4.2.
>>> While Congestion Control is one of my favorite topics, WebRTC does not
>>> specify much in that regard (
>>> https://www.rfc-editor.org/rfc/rfc8834.html#section-7). So IMO, talking
>>> about existing CC and BWE algorithms in WebRTC libraries is more suited for
>>> as an implementation guideline and not part of the specification. Up to now
>>> we have avoided including that kind of implementation guidelines in the RFC.
>> I don't think we need to describe existing CC or BWE algorithms in this
>> specification. There are existing CC algorithms tested and implemented for
>> WebRTC communication based on the guidance available in RFC8834. However,
>> WebRTC was not directly designed for ingest of streaming media and as
>> mentioned CC requirement (https://www.rfc-editor.org/info/rfc8836) in
>> RFC 8834 does not include streaming considerations. Hence, what we can
>> simply say one need to consider the use of existing WebRTC CC algorithms
>> and those might not be sufficient for the ingest use case covered in this
>> specification. If we have more details - we can very well add them. As this
>> document stands it does not talk about changes required in CC
>> considerations at all.
> While I don't mind adding some non-normative text, I have been fighting
> against FUD on werbtc usage on streaming for so long that I would strongly
> oppose adding any ill-defined, negative tone description not fully backed
> by technical facts.
> In that regard, one of the WHIP goals is (as stated in the introduction):
> *Enables ingestion on both traditional media platforms and WebRTC
> end-to-end platforms, achieving the lowest possible latency.*
I would note the implication of "not achieving lowest possible latency" is
not clear in this specification while ingest is usually a case to highest
throughput. So, which one is the primary goal here? - my guess is - it is
about achieving lowest possible latency while achieving highest possible
throughput. None of the webrtc implementations I know of focuses on highest
throughput when it comes to congestion and rate control - if you are saying
I can take any webrtc implementation ( say libwebrtc which implements a
congestion control algorithm) and establish signaling with WHIP for ingest
case and it would simple work, then we would actually need "fully backed by
technical facts" regarding that.

> This matches perfectly with the requirements in RFC 8834:
> *These algorithms have also been used for transfer of media streams that
> are viewed in a non-interactive manner, such as "streaming" video, where
> having the data ready when the viewer wants it is important, but the exact
> timing of the delivery is not.*
> *When handling real-time interactive media, the requirements are
> different. One needs to provide the data continuously, within a very
> limited time window (no more delay than hundreds of milliseconds
> end-to-end).*
> *The congestion control algorithm MUST attempt to provide
> as-low-as-possible-delay transit for interactive real-time traffic while
> still providing a useful amount of bandwidth.*
Where is this stated?

> If the latency budget is higher (in the range of 1s), then different
> congestion control/bwe could be implemented, although we would be moving
> out of the original scope of WHIP.

So WHIP has a latency scope, beyond which this might not be usable. I
haven't noted such scope this specification. It seems to me very important
to state such latency range.

>>>> 2. As HTTP proxying is common, why should this specification not have
>>>> any
>>>> discussion on WHIP client behind a proxy. I am assuming it does not
>>>> change much
>>>> but I was at least expecting some considerations for such a scenario.
>>> We have been advised by the  HTTP directorate review to avoid
>>> re-specifying HTTP and not include text that is already covered by the HTTP
>>> RFCs. In that regard, if the WHIP client/server are not required to have
>>> any special consideration when working with proxying, I would prefer not to
>>> include any reference at all.
>> Yes, I would also advice not to re-specify HTTP :-).  That also means we
>> need to consider when the WHIP client is behind a proxy then how the ICE
>> works between media server and the WHIP client. As there was no mention of
>> WHIP client behind a HTTP proxy case hence the discuss was to make sure we
>> have considered the case and decided no special considerations would
>> require for WHIP to function. I believe it would great if we actually
>> record this in the specification explicitly.
> An HTTP proxy won't affect ICE in any means, just the HTTP POST carrying
> the SDP O/A. If there is a gateway blocking/filtering UDP traffic, then
> that's exactly what ICE is designed for and I don't feel we need to add any
> further note about it.

I think if this specification says, WHIP is fully compliant with
, then it will solve my concerns. This specification actually should say -
what is a "HTTP-based protocol" in this context?

>> .
>>>>   # Figure 1 is also a bit confusing. The WHIP session is described as
>>>>   allocated http resources at WHIP endpoint, but draws WHIP session as
>>>>   something out of WHIP endpoint.
>>> The whip sesion is an HTTP resource allocated BY the WHIP endpoint, not
>>> at the WHIP endpoint.
>> OK, should we the consider the WHIP endpoint as the origin server
>> according to the section 9.3.3 of RFC 9110 ?
> Yes, I think that would be correct. As I still have to answer the review
> of the HTTP directorate, I will add the question there so they can provide
> guidance.

Sounds good.

> Best regards
> Sergio