Re: [nwcrg] [irsg] IRSG review of draft-irtf-nwcrg-bats-03

[Marie-Jose Montpetit <[e-mail]>]

Many thanks to you :)

Marie-José Montpetit, Ph.D.
[e-mail]



From: David R. Oran <[e-mail]> <[e-mail]>
Reply: David R. Oran <[e-mail]> <[e-mail]>
Date: December 5, 2022 at 11:01:01 AM
To: Shenghao Yang <[e-mail]> <[e-mail]>
Cc: The IRSG <[e-mail]> <[e-mail]>, Nwcrg <[e-mail]>
<[e-mail]>
Subject:  Re: [irsg] [nwcrg] IRSG review of draft-irtf-nwcrg-bats-03

I looked over -04 and my comments have been addressed. Thank you! While I
didn’t do a detailed re-read (looking mostly at the sections I had
commented on) I did notice a few typos that should be fixed:

in 4.2, s/packets of a batche on the same path/packets of a batch on the
same path/
in 6.2, s/reduancy/redundant/

Also, I saw the good comments in an email from Vincent, which should get
covered in a revision.

I’m happy for this to advance past IRSG review as soon as you can issue a
further update.

Many Thanks,
DaveO.

On 3 Dec 2022, at 12:29, Shenghao Yang wrote:

Dear David,

We just submitted a revised version based on comments.
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/04/

See the point-to-point response below. The security related issues took us
some time to revise.


Best,

Shenghao

On Jun 22, 2022, at 21:43, David R. Oran <[e-mail]> wrote:

I reviewed draft-irtf-nwcrg-bats-03 as designated reviewer for the IRSG.
The document is in very good shape and the technical content sound. I have
just a few minor comments and some grammar/typographic nits for the authors
to consider prior to publication.
Minor Comments

   -

   In the introduction (paragraph 2), you should mention more than just
   interference as something that makes a wireless channel unreliable. There’s
   also fading, multipath, etc.


We mentioned fading and multiparty in the revision.


   -

   Discussion of multipath doesn’t show up until quite far along in the
   document, and in a few places the wording seems to restrict operation to a
   single receiver. There is in fact good discussion of multicast in the
   research questions section, so I suggest just a brief mention in the
   introduction that BATs is intended to work well in both unicast and
   multicast environments, possibly with a forward reference to the later
   discussion.


Multicast is mentioned in the introduction with referring to Sec 4.


   - On p7, the way the requirements on coded packets are laid out is bit
   difficult to follow. I suggest starting each set with something like a
   description list, with who the requirement applies to as the lead-in, for
   example:
   -

   *Encoder* - the encoder DDP must deliver each coded packet with for
   following:
   - BID: batch ID

   *Recoder* - The DDP MUST deliver the following information to each
   recorder:
   - M: batch size
      - q: recoding field size

   *Decoder* - The DDP MUST deliver the following information to each
   decoder:
   - M: batch size
      - q: recoding field size
      - K: the number of source packets
      - T: the number of Octets in a source packet
      - DD: the degree of distribution

The presentation style of this part is revised.


   -

   p9, beginning of section 2.2.4 says “A destination node needs the data
   transmitted by the source node”. Well, sure, but are you trying to say
   something beyond the obvious here? If so, it isn’t coming through.

This paragraph is rewritten.


   -

   In the various field descriptions and the equations, you use the letter
   “O” for “octets”. This slowed me down a bit as I had to think each time
   that you didn’t mean zero (“0”), despite the fact that the glyphs are in
   fact distinguishable in all three target renderings. It might be a pain to
   fix all of these, but I do think a better choice would either be “T” (which
   you use in the example above as a parameter for the decoder), or a
   two-letter variable name like “OC”.


O is changed to CO (the first two letters of coefficient).


   -

   On p12 you say “A common primitive polynomial should be specified for
   all the finite field multiplications over GF(256). Is this actually a MUST
   for the operation of the code?

“Should” is changed to “MUST"


   -

   In the discussion of routing issues, on p18, you talk about the
   possibility of different batches being sent on different paths to achieve
   multipath gain. Is there a reason why batches can’t be similarly split and
   sent over different paths? If not, why not?

We add the discussion about whether to transmit the packets of a batch on
the same path or different paths for unicast and multicast.


   -

   Section 4.3 is titled “Application-related issues”, however most
   (perhaps all?) of the discussion isn’t actually about applications but
   about usage and deployment scenarios over different kinds of network
   technologies and topologies. Suggest renaming this “Usage Scenario
   Considerations” or something similar and if there are in fact application
   issues (e.g. multimedia, IoT, etc.) split those out in a separate section.

The section title is changed to “Usage Scenario Considerations”.


   -

   In section 6 on security considerations you address eavesdropping well,
   but don’t talk at all about traffic analysis. Are there interesting factors
   in BATs affecting the ability of traffic analysis to figure out what is
   happening with the application data flows, e.g. does BATs produce
   detectable timing or padding behavior that can be leveraged better than
   non-coded data, or perhaps conversely make things harder for an adversary?

A new subsection is added to discuss traffic analysis. See 6.2.


   -

   The discussion of attestation in section 6.2 left me feeling a bit
   un-satisfied, given that the protocol doesn’t actually provide provenance
   (i.e. the attestation of the chain of coders/recoders does not seem
   explicitly bound into the data streams). Simple origin authentication (e.g.
   using signatures) doesn’t seem to be adequate. Am I missing something here?

The pollution attack part is rewritten. See 6.3.

Nits

   -

   p7, s/DD[i] is the possibility/DD[i] is the probability/
   -

   p12, s/addition is an logical XOR/addition is a logical XOR/
   -

   p17, s/increasing too much end-to-end latency/increasing end-to-end
   latency too much/
   -

   p17, s/achieves the mulicast/achieves the multicast/

[End of review]
_______________________________________________
nwcrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/nwcrg


_______________________________________________
nwcrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/nwcrg

DaveO