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

[Shenghao Yang <[e-mail]>]

Dear Colin, David and Vincent,

Thank you for your quick comments. An update is submitted.
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/06/

We are happy to cite RFC 9265, which is very relevant.

2^(d-M)T>=2^T is changed to 2^(-(d-M)T)<=2^(-T)


Shenghao


On Tue, Dec 6, 2022 at 4:01 AM Colin Perkins <[e-mail]> wrote:

> Thank you to Shenghao and the authors for the update, and to Dave and
> Vincent for the speedy response.
>
> It seems the changes address the major review comments, but there are a
> few minor issue remaining. If it’s possible to issue an update to address
> those, we can then move this draft forward.
>
> Regards,
> Colin
>
>
>
> On 5 Dec 2022, at 16:00, David R. Oran wrote:
>
> 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
>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg
>
>