Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

Vincent Roca <> Tue, 18 June 2019 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DE97120416; Tue, 18 Jun 2019 12:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TEl-zurHVg0z; Tue, 18 Jun 2019 12:25:31 -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 4FB8B120404; Tue, 18 Jun 2019 12:25:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.63,390,1557180000"; d="scan'208,217";a="388012794"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2019 21:25:27 +0200
From: Vincent Roca <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2914CFB1-AE64-440E-ABEB-92BD46FBA24A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 18 Jun 2019 21:25:26 +0200
In-Reply-To: <>
Cc: Vincent Roca <>, The IESG <>, "" <>, "" <>, "" <>
To: Benjamin Kaduk <kaduk@MIT.EDU>
References: <> <> <359EC4B99E040048A7131E0F4E113AFC01B33926C6@marathon> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jun 2019 19:25:34 -0000


I said in my previous email there was an unanswered comment.
Here it is, reflected in the brand new -16 I-D version.

> >  Benjamin Kaduk (was Discuss) No Objection
> > Comment (2019-05-28)
> >
> > Appendix B
> >
> > side note: I don't propose to have you redo the analysis, but looking at
> > the small sequences generated using seed values from 0 to 1,000,000 - 1
> > is not terribly representative of the FEC usage, since the seed values
> > there are limited to the range from 0 to 16k.  Comprehensive statistics
> > on the 16k possible sequences (corresponding to the 16k possible repair
> > keys) of 20 pseudo-random numbers would be more compelling.

[VR] I agree on the principle: PRNG usage is limited to 65536 different seeds (we re-use
a 16-bit field to carry this seed as the repair key) and the above tests are not in line with
the PRNG actual usage. I’ve done complementary tests limited to these 65536 seeds
and updated the document. Of course convergence to a uniform distribution is less good,
but I don’t see any risk for the RLC FEC Schemes efficiency.

   Since the RLC FEC Schemes use of this PRNG will be limited to 16-bit
   seed values, we carried out the same test for the first 2^^16 seed
   values only.  The distribution (not shown) is of course less uniform,
   with value occurences ranging between 6.2121% (i.e., 81,423
   occurences out of a total of 65536*20=1,310,720) and 6.2948% (i.e.,
   82,507 occurences).  However, we do not believe it significantly
   impacts the RLC FEC Scheme behavior.

> > Also, for the scenario presented in Figure 12, I'm not sure I agree with
> > the claim that "although the distribution is not perfect, there is no
> > major bias".  Not in that I think there is bias, but in that I think
> > that we should not expect the average occurrences column to be a
> > constant -- the numbers here seem largely within the expected sort of
> > variances for this type of sampling.
> [VR] I need to give it a second thought... I've submitted -15 without
> considering this comment and will see how to adress it in -16.

[VR] I’ve left the document unmodified. In fact, if we compare these results with the
one achieved with the Park-Miller LC PRNG we see that the second one does not
work at all and MUST (yes) be avoided, while TinyMT32 even after truncation to 4-bits
is reasonably good. That was my initial idea.

Thanks for your feedback.

  Vincent and Belkacem