Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt

[Arno Bakker <[e-mail]>]

Hi Yunfei (et al)

Thanks for the feedback. Responses inline.

On 20/06/2012 09:09, zhangyunfei wrote:
> Hi Arno and Riccardo (Speaking individually),
   >
> 2) bin numbers in 1^st paragraph: Since there are at least two schemes
> introduced in section 4, the range scheme should be stated here as well.

Sorry, forgot to update the introduction section in a vain effort to 
keep changes to a minimum. Scheduled for -03.


> 3)Merkle hash tree in section 2.2：Occur for the first time without
> explaining before.It's better to add the term in section 1.3.

Done for -03.


> 4)INTEGRITY in section 2.2: It should be stated that this message is not
> used all the time.

Clarified in -03.


> 5)Section3.3： The sentence "it MUST send a ACK message containing a
> chunk specification for C". MUST or SHOULD.

Riccardo is looking into sending batched acknowledgements in 
relationship to the latest LEDBAT draft, so we may update this section. 
At present, it is a "MUST" when run over unreliable transports.


> 6)Section 3.9, since TCP is abandoned by PPSPP, do we need to explain
> the related case?

Good that you mention transports, AFAIK that still needs to be 
discussed. Candidates are:

* UDP with congestion control (e.g. LEDBAT)
* RTP
* Both UDP+cc and RTP

I see no direct use case of TCP, but IMHO we should not exclude it either.

Support for RTP may make the standard more appealing to the RTCWEB 
crowd. Perhaps we should ask them for an opinion on this issue.
Yunfei/Stefano, do you know somebody we could ask?


> 7)Section 4.3 PEX_ADD, no explanation before.

PEX_ADD was renamed to PEX_RES except in this location :-(


> 8)Section 6: I suggest to exclude this section because it involves a
> over-strong limitation:fixed chunk size.Furthermore I am not clear of
> the necessity of this scheme.Just as the background of section 7?

IMHO, fixed-size chunks will be rather common with static content,
and the ability to detect content size is a nice property to achieve 
minimal metadata (cf. info centric networking)

In any case, the concept of peak hashes enhances security and eases 
implementation, therefore I think it should be explained in the draft. 
The peak hashes provide a secure method of determining (a) the height of 
the MHT and (b) more importantly, how many chunks there are at the base 
of the tree. This helps to protect against malicious peers sending 
confusing information, e.g. a HAVE for a chunk outside the actual chunk 
range. The ability to judge incoming information as being good or bad
greatly eases implementation (otherwise you may need e.g. majority
votes on how many chunks there are, etc.)

Peak hashes also ease implementation in another respect. With the 
knowledge about the tree they provide, datastructures can be
preallocated, such as the storage of the MHT and chunk availability 
bitmaps. Pre-allocated datastructures are easier to implement than data 
structures that have to dynamically adapt.


> 9) Section 7:for the similar reason, remove the section 7.1.1

I don't quite follow this comment. Live streaming is not dependent on 
fixed-sized chunks and mini Merkle Hash Trees are already a common way 
of efficiently authenticating live data (Wong and Lam scheme). IMHO, it 
makes sense to extend to extend this mechanism to a big tree. This would 
enable people that tune in late to a show and want to watch it from the 
start to use the same swarm as the live watchers.


> 10)Section 9.3.2, why placed here? I suggest to remove this section.

I'd like to start the discussion on which transport to use (see above)
and then update this part of the spec, if that's alright.

Regards,
     Arno