Re: [rmcat] WG last call: draft-ietf-rmcat-video-traffic-model-04

Colin Perkins <csp@csperkins.org> Sun, 15 July 2018 19:55 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36AB130E01; Sun, 15 Jul 2018 12:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 wFHciHOIt5UH; Sun, 15 Jul 2018 12:55:01 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 33987130E03; Sun, 15 Jul 2018 12:55:01 -0700 (PDT)
Received: from [2001:67c:1232:144:6482:406b:2501:dffb] (port=54038) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <csp@csperkins.org>) id 1fen6c-0005lC-Hv; Sun, 15 Jul 2018 20:54:59 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <617E838F-65E8-4B6B-B6BA-8E0AC9152A22@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_75391C63-4A65-46F4-B520-AD17CA2801FA"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 15 Jul 2018 15:54:48 -0400
In-Reply-To: <CAKmxLjWDx2HYuPeJgKWqnKYpfMAfPs36qnJkO2TkSr_rpOOCBQ@mail.gmail.com>
Cc: rmcat WG <rmcat@ietf.org>, draft-ietf-rmcat-video-traffic-model@ietf.org
To: Fu Jiantao <fuji246@gmail.com>
References: <49C0BFE8-B4B9-40AB-ABE6-07F326CC595F@csperkins.org> <CAKmxLjWDx2HYuPeJgKWqnKYpfMAfPs36qnJkO2TkSr_rpOOCBQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 14
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/suMnN5BGWQMS6gWSzOqrGpXDFuU>
Subject: Re: [rmcat] WG last call: draft-ietf-rmcat-video-traffic-model-04
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jul 2018 19:55:05 -0000

Thanks for the comments!

After reading it again, I’d also note that:

The draft talks about “RMCAT algorithms”, but should probably talk about “RTP congestion control algorithms”, since the final RFC will outlive the RMCAT working group.

The draft needs a security considerations section. I can’t of anything to include other than a statement about the importance of congestion control to stable operation of the network, and for RTP flows the importance of testing congestion control with realistic traffic.

Cheers,
Colin




> On 12 Jul 2018, at 21:59, Fu Jiantao <fuji246@gmail.com> wrote:
> 
> Hi, 
> 
>   Some comments below:
> 
>   1. In Abstract 
> 
> "
>    The second model is trace-
>    driven, and emulates the encoder output based on actual encoded video
>    frame sizes from a high-resolution test sequence.
> "
> 
> is that based on both encoded video frame interval and frame size? 
> 
> 2. In section 4, in the graph and description is misleading to me, the synthetic video codec takes raw video frames, but not in realtime like real video codec,  it's two steps process, the first step is to 
> 
>  1) for statistic model, fitting from emperical data to get parameters
> 
>  2) for trace-based model, gather meta data like frame size, frame type etc 
> 
> The first step is like pre-process, and the second step is to feed that into the synthetic video codec in realtime.
> 
> 3. In section 4. "Frame resolution XY", that is actually the target frame resolution, right? this may also be affected by subscription from remote receiver, for example when remote is a mobile client with a small screen.
> 
> - Jeromy
> 
> Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>> 于2018年6月20日周三 上午1:49写道:
> This is to announce a working group last call on “Modeling Video Traffic Sources for RMCAT Evaluations” (draft-ietf-rmcat-video-traffic-model-04). 
> 
> Please send any final comments to the working group mailing list and the authors by 20 July 2018 (the date of the RMCAT session at IETF 102). If no substantive comments are received by that time, we intend to submit this draft to the IESG for publication as an Informational RFC.
> 
> Colin (for the RMCAT chairs)
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
> 



-- 
Colin Perkins
https://csperkins.org/