Re: [Detnet] Question about using blockchain as DetNe use case

["Grossman, Ethan A." <[e-mail]>]

Hi Daniel,
In the IESG review of the DetNet Use Cases draft there is a question about whether bounded worst case latency is critical to the blockchain consensus process, so I would like your view.

We understand that the consensus process will have higher throughput if the average transmission time is minimized, but is it critical that the worst case packet transmission delay (latency) be minimized and/or bounded? For example, would you rather have:

  1.  A network in which the latency values for most packets was very low, but occasionally there was a “worst case latency packet”, such that the average latency over time (i.e. including many short and a few long) was “shortest” (compared to option B below).
Or

  1.  A network in which the worst case latency was bounded, and shorter than the “worst case latency packet” time (from option A above) but the average latency over time was longer than “shortest” (from option A above). That is, this network provides lower worst-case latency but higher average latency (compared to option A above).
If your answer is “B” then please explain why. If you answer is “A” then I will modify the draft text to make this point clearer, i.e. that it is important to minimize average latency in order to optimize this application (as opposed to optimizing (and bounding) worst case latency as is the case for some of the other use cases).

The text from the draft is:
The challenge of blockchain network operation is not overall data
rates, since the volume from both block and item stays between
hundreds of bytes to a couple of mega bytes per second, but is in
transporting the blocks with minimum latency to maximize efficiency
of the blockchain consensus process.

Thanks,
Ethan.

From: [e-mail] <[e-mail]>
Sent: Thursday, November 16, 2017 7:27 PM
To: [e-mail]
Cc: [e-mail]; Grossman, Ethan A. <[e-mail]>
Subject: 答复: Re: [Detnet] Question about using blockchain as DetNe use case


Norm,

Thanks for your comment.

I understand the fact the blockchain traffic is bursty would inevitably bring some waste to the reserved bandwith, which would happen in all of the scenarios where the data rate is variate.

but fortunately it's inherent in blockchain the metadata size (both the "transaction" and "blocks") is fixed or could at least be pre-calculated, so in a running blriockchain the bw reserved could be set strictly as the specified datarate rather than a maximum covering a variaty of datarates.

thanks again.











黄光平 huangguangping



预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product Operation Division


[cid:image001.gif@01D493C7.3EC52730]

[cid:image002.gif@01D493C7.3EC52730]
南京市雨花区软件大道50号中兴通讯1号楼
R&D Building, ZTE Corporation Software Road No.50,
Yuhua District, Nanjing, P..R.China, 210012
M: [phone]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zte.com.cn_&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=o70oZ2kUSjKLvmrL51To4giAVx8MYGkodiHsSU6toJ4&m=99jed747zh_TTHHoFTD9ikRT6orzqEGIQ8WmUphR4XU&s=adhAU3RHBRY8ulDKY-esA7IUaEYE5h-WUuoVByw2-i4&e=>

原始邮件
发件人： <[e-mail]<mailto:[e-mail]>>;
收件人：黄光平10039714;
抄送人： <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;
日 期 ：2017年11月17日 11:08
主 题 ：Re: [Detnet] Question about using blockchain as DetNe use case


Guangping,

Thanks for the reply.  Let me explain a little better what and why I'm asking:

It's not possible to guarantee both bounded latency and reliable delivery to an arbitrarily high load with a finite number of buffers in the network.  The way that DetNet can assure reliable delivery to bitcoin is:

  1. Every point-to-point bitcoin connection has a certain bandwidth reserved for its use.
  2. A bitcoin host must not transmit data faster than its reserved bandwidth; any excess packets are discarded.
  3. Unused bandwidth on a bitcoin reservation is NOT available to any other reserved flow, bitcoin or not; it is available only to non-DetNet traffic.
  4. Reservations can never oversubscribe a link.

What this means is that, if a burst of bitcoin activity would exceed the bandwidth of a reservation, the bitcoin application has to buffer its transmissions and meter them out at no more than the contracted rate.  This adds to the latency, of course.  How much  it adds would depend on the size of the burst.  It would take some analysis to look at the transmission rate as a function of time and the worst-case acceptable latency, in order to come up with the optimal value for a bandwidth contract.  The bigger the bandwidth,  the more expensive the reservation, because of points 3 and 4.

In reading the use cases draft, I understood that reliable delivery is attractive to bitcoin, but the description of the application did not make me confident that the fixed bandwidth aspect would be acceptable.  I'm always glad to find a new application of  DetNet, but if the activity of bitcoin is bursty, it might not be a good fit.  I certainly hope it is.

How bursty is bitcoin?

-- Norm
________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]]
Sent: Wednesday, November 15, 2017 6:41 PM
To: Norman Finn
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: 答复: [Detnet] Question about using blockchain as DetNe use case

hi Norm,

bitcoin is actually a public blockchain which is running in the open internet. here we're address specifically the private blockchain.

blockchain runs in a mode of p2mp among its participating nodes while it's actually running p2p in the level of network (L3/L4)  based upon best-effort under current scenario. its consensus mechanism demands strictly  every transmission of the data be delivered successfully on each node, otherwise the failed (packet-loss, expiry delivery etc)transmission has to tranported again.

the unreliability and the latency incurred is especially intolerable in the private blockchain applications.

so far as the fixed bw is concerned, blockchain actullay would not consume too much for its quite limited metadata transmission.







黄光平 huangguangping



预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product Operation Division


[cid:image001.gif@01D493C7.3EC52730]

[cid:image002.gif@01D493C7.3EC52730]
南京市雨花区软件大道50号中兴通讯1号楼
R&D Building, ZTE Corporation Software Road No.50,
Yuhua District, Nanjing, P...R.China, 210012
M: [phone]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zte.com.cn_&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=o70oZ2kUSjKLvmrL51To4giAVx8MYGkodiHsSU6toJ4&m=99jed747zh_TTHHoFTD9ikRT6orzqEGIQ8WmUphR4XU&s=adhAU3RHBRY8ulDKY-esA7IUaEYE5h-WUuoVByw2-i4&e=>



发件人： <[e-mail]<mailto:[e-mail]>>;
收件人：黄光平10039714; <[e-mail]<mailto:[e-mail]>>;
抄送人： <[e-mail]<mailto:[e-mail]>>;
日 期 ：2017年11月16日 10:03
主 题 ：[Detnet] Question about using blockchain as DetNe use case


I know little about the applications bitcoin.  I can easily appreciate its need for reliability, but I have a question about bandwidth.

Are bitcoin applications comfortable with the fixed bandwidth aspect of DetNet?

That is, an app cannot exceed the BW of a flow, and unused BW is not available to other DetNet flows.  So, I take it that bitcoin is either not bursty, or can afford wasted bandwidth.

-- Norm