Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 4.

Benjamin Kaduk <> Wed, 26 May 2021 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73A5F3A1514; Tue, 25 May 2021 17:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v_kXCeIdhK4d; Tue, 25 May 2021 17:23:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C2623A1516; Tue, 25 May 2021 17:23:36 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 14Q0NJp2014711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 20:23:24 -0400
Date: Tue, 25 May 2021 17:23:19 -0700
From: Benjamin Kaduk <>
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= <>
Cc: The IESG <>,,,,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 4.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 May 2021 00:23:40 -0000

Hi Gunnar,

On Tue, May 25, 2021 at 12:29:51PM +0200, Gunnar Hellström wrote:
> Benjamin,
> Continuing the answers with the last part.,

Thank you for going through them all.  To be clear, I was not waiting for
you to finish before I started replying -- I just had a deadline earlier
today and did not have a chance to do much with my email sooner.  Having
the content chunked up into multiple pieces can make it easier to manage.

This is the only message I'm going to respond to, though, since I basically
have nothing further to say.  (I've already updated my ballot position to
remove the Discuss.)  I'm really impressed with how you took my comments
and turned them into improved text in the document, especially in the
places where I did not have a clear proposal.  I also appreciate your
explanations in the places where my questions did not make sense or are
already covered by some of the fundamental documents in this space; the
gaps in my knowledge are slowly getting filled in.

> Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
> [GH]Again, thanks for a thorough review and many good proposals for changes.

I must thank you again for your thorough responses; I feel like I am not
doing them justice by only sending this one short note, but do not want to
make you read through a repetitive set of "yes", "this sounds good", "thank
you", etc.

I read through the changes in the already-uploaded -19 (thank you again!),
and there were only two items that might be worth following up on (both in
section 3.16.3 of the -19):

You had proposed:

[GH] Would it be sufficient to insert the words "and reordering" in the
first two sentences in the paragraph to read: "The receiver SHALL monitor
the RTP sequence numbers of the received packets for gaps and packets
out of order.  If a sequence number gap appears and still exists after some
defined short time for jitter and reordering resolution, the packets in the
gap SHALL be regarded as lost."

I don't think this made it into the -19; my preference is to use your
proposed text that includes mention of reordering, but I do not insist on

There was also a mention about the procedures for extracing T140blocks with
the redundancy procedure, where we currently say "T140blocks SHALL be
extracted in the following way.  The description is adapted to the default
redundancy case using the original and two redundant generations."  While I
am inclined to agree that the extension to the generic case with other
levels of redundancy is something that the reader can be expected to
perform, it feels a little incomplete to say that something "SHALL be
[done] in the following way" but give a not-complete/not-generic procedure.
Only for that reason do I prefer to have an explicit indication that the
procedure might need to be adjusted for a different level of redundancy; as
for the previous point, I do not insist on any change, though.

Thanks again,