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

Dear Shenghao,

Thank you - once Vincent confirms this addresses his comment, I’ll 
move this forward.

Colin

On 6 Dec 2022, at 16:24, Shenghao Yang wrote:

> 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 <csp@csperkins.org> 
> 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 <daveoran@orandom.net> 
>> 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
>> nwcrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nwcrg
>>
>>
>> _______________________________________________
>> nwcrg mailing list
>> nwcrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nwcrg
>>
>> DaveO
>>
>> _______________________________________________
>> nwcrg mailing list
>> nwcrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nwcrg
>>
>>