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

From: Arno Bakker <[email-masked]>
Date: Wed, 11 Jul 2012 09:21:11 +0200

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

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 11 Jul 2012 12:33:58 -0400

> Yunfei/Stefano, do you know somebody we could ask?

I would prefer to simply go with UDP+cc and keep it simple.
The RTCWEB approach involves a stack of other crap that
does not seem to be of much value for PPSP; they are not
using purely RTP.

-- 
Wes Eddy
MTI Systems

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 11 Jul 2012 12:41:35 -0400

> * UDP with congestion control (e.g. LEDBAT)

I'm wondering if LEDBAT is the right choice, given that its
design is to let itself get drowned out.  LEDBAT made sense
for BitTorrent streams running in the background, but I don't
think it makes as much sense for live-streaming.

It seems that TFRC might be more appropriate to me.

-- 
Wes Eddy
MTI Systems

---

From: zhangyunfei <[email-masked]>
Date: Mon, 16 Jul 2012 14:11:15 +0800

Same impression as Wes. To the best of my knowledge, LEDBAT is designed to be for "lower priority" apps, who is mainly running on top of TCP (at least UDP and TCP are co-functioning and can switch each other). It seems ppsp apps are neither"lower priority"apps when competing with other traffics nor requiring both UDP and TCP running and switching.
So a UDP+cc(needn't considering the TCP effect) solutions seems appropriate.

BR
Yunfei

zhangyunfei

From: Wesley Eddy
Date: 2012-07-12 00:41
To: arno
CC: ppsp
Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt

-- 
Wes Eddy
MTI Systems
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Arno Bakker <[email-masked]>
Date: Mon, 16 Jul 2012 09:23:29 +0200

On 16/07/2012 08:11, zhangyunfei wrote:
> Same impression as Wes. To the best of my knowledge, LEDBAT is designed 
> to be for "lower priority" apps, who is mainly running on top of TCP (at 
> least UDP and TCP are co-functioning and can switch each other). It 
> seems ppsp apps are neither"lower priority"apps when competing with 
> other traffics nor requiring both UDP and TCP running and switching.

Hi

I think LEDBAT is useful for seeding (VOD) peers. Once they have
downloaded the content they should ideally contribute back to the P2P
network, but without causing disturbance for their user.

It can also be useful in networks which currently have overcapacity. In
that case, downloading at higher than the bitrate is effective use of
resources (a megabit/s not used is a megabit/s lost), but the
faster-than-required download should not infere with other activities of
the user. I.e. LEDBAT should limit it when required, whilst not dropping
the speed below approx. bitrate.

Riccardo knows more about this, so perhap he can comment.

CU,
    Arno

---

From: Riccardo Petrocco <[email-masked]>
Date: Mon, 16 Jul 2012 15:48:32 +0200

Hi,

As Arno explained in the previous mail, LEDBAT was chosen to increase the
on-line
time of seeders.
The main problem with any P2P systems is the supply of bandwidth. With an
oversupplied
swarm, there is usually no problem in delivering the stream on time. If the
users don't see
any drop in performance by keeping on seeding content they already watched,
they might
stay longer in the swarm.

Wesley is definitely right, as for live-streaming LEDBAT is not the best
candidate.
I wonder if we can keep LEDBAT, as it's the ideal cc for file sharing and
VoD content, and
adjust it's queuing target delay value, to act as TCP, in case of a
live-streaming swarm.

BR,
Riccardo

2012/7/16 Arno Bakker <[email-masked]>