[Detnet] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt

[<[e-mail]>]

Timely delivery of blockchain data traffic (frequent and low-speed p2mp)with bounded latency and packet loss is the major requirement for the underlying network, I understand some priority-based strategies in the upper levels could also to some degree achieve this fully or partly at least. The mechanisms designed in detnet (congestion protection/explicit route/service protection) should be the best among the available solutions as I can see.

Thanks for your comments.

Daniel.



















黄光平 huangguangping






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









南京市雨花区软件大道50号中兴通讯1号楼 
R&D Building, ZTE
Corporation Software Road No.50, 
Yuhua District, Nanjing, P..R.China, 210012 
M: [phone] 
E: [e-mail] 
www.zte.com.cn








原始邮件



发件人： <[e-mail]>
收件人： <[e-mail]> <[e-mail]>黄光平10039714 <[e-mail]>
抄送人： <[e-mail]> <[e-mail]>
日 期 ：2017年07月14日 01:56
主 题 ：Re: [Detnet] 答复: Re:  答复: Re:  答复: Re:  转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt







So it sounds like this would be a DetNet application (bandwidth reservation), removing the requirement for the blockchain application layer to deal  with the loss and unbounded latency, but on top of that some (non-DetNet) priority mechanism would also be used to minimize latency?


 



From: Balázs Varga A [mailto:[e-mail]] 
 Sent: Thursday, July 13, 2017 7:50 AM
 To: Norman Finn <[e-mail]> [e-mail] [e-mail]
 Cc: Grossman, Ethan A. <[e-mail]> [e-mail] [e-mail]
 Subject: RE: [Detnet] 答复: Re: 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


Hi,


 


I think this cautionary note provides a very good border between applications requiring detnet or not.


Reading through the mailing I have read about “retransmission” what means for me that dealing with


loss and unbounded latency is part of blockchain technology. Is that correct?


 


If I read it correctly the ultimate goal is to optimize “service delivery delay” to be as minimum as possible.


One can achieve this via minimizing loss and delay. That points for me more towards strict priority + strict


bandwidth reservation.


 


Please correct me if I have missed something.


 


Thanks & Cheers


Bala’zs


 



From: detnet [mailto:[e-mail]] On Behalf Of Norman Finn
 Sent: 2017. július 11. 10:59
 To: [e-mail] [e-mail]
 Cc: [e-mail] [e-mail] [e-mail]
 Subject: Re: [Detnet] 答复: Re: 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


A cautionary note:  Please remember that DetNet/TSN offers a bound on the worst-case maximum latency, not minimum latency.  The average  latency delivered by DetNet is typically worse than the average latency delivered by strict priority.  But, the latency is never greater than the contracted limit, and packets are not dropped due to congestion.
 
 -- Norm


 
--------------------------------------------------------------------------------



From: [e-mail] [[e-mail]]
 Sent: Tuesday, July 11, 2017 1:53 AM
 To: [e-mail]
 Cc: Norman Finn [e-mail] [e-mail] [e-mail]
 Subject: 答复: Re: [Detnet] 答复: Re: 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt


There're a couple of allied blockchain applications in finance & security industry in China (might be more in other regions), in which part of the transaction recording and approval is executed above blockchain rather than the traditional  centralized systems. The onging process is far from real-time, although real-time or at least as low latency as possible is going to be the dominant requirement as far as the service is concerned. 

Apart from the application-level process optimization, it also would be greatly helpful if the underlying network provides some deterministic network services to reduce the network-level latency to the minimum.

 

In general, the data & information delivery efficiency (in terms of latency in particular) of blockchain could be critical. The network might support this with detnet servces.

 

Thanks.

Daniel

 

 

 

 


 


黄光平 huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P..R.China, 210012 
 M: [phone] 
 E: [e-mail] 
 www.zte.com.cn







原始邮件


发件人： <[e-mail]>



收件人：黄光平10039714  <[e-mail]>



抄送人： <[e-mail]>  <[e-mail]> <[e-mail]>



日 期 ：2017年07月11日  16:24



主 题 ：Re: [Detnet] 答复: Re:  答复: Re:  答复: Re:  转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


Hi Daniel,


 


Is there a way that you can give us an example of such applications ?


 


Thanks,


 


Patrick


 



From: "[e-mail]" <[e-mail]>
 Date: Tuesday, 11 July 2017 at 10:19
 To: "[e-mail]" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>,  "[e-mail]" <[e-mail]>, Patrick Wetterwald <[e-mail]>,  "Maik Seewald (maseewal)" <[e-mail]>
 Subject: 答复: Re: [Detnet] 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt



 


Hi Norm,

Thanks for your detailed clarification about bandwidth reservation. The conditions you listed below are totally acceptable to blockchain applications.

 

Thank again.

 

Daniel

 

 

 

 

 


 


黄光平 huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P..R.China, 210012 
 M: [phone] 
 E: [e-mail] 
 www.zte.com.cn







原始邮件


发件人： <[e-mail]>



收件人：黄光平10039714



抄送人： <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>



日 期 ：2017年07月11日  16:11



主 题 ：Re: [Detnet] 答复: Re:  答复:  Re:  转发:  New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


Let me make very sure that we are in agreement.
 
 To use TSN, each transmitter would require a bandwidth reservation for some specific bandwidth.  As an example, let's say that each reservation is for 50kbps.
 
 Then,
 
  1. Every transmitter must constraint itself to transmit no more than its contracted 50 kbps.  To the extent that it transmits any faster than its contract specifies, the packets in excess of the contract WILL be dropped.
  2. The network will never oversubscribe a link.  If the network is configured to accept a maximum of 800 kbps on a given physical link, then the network will accept at most 16 reservations that pass through that port.
  3. A transmitter whose reservation is rejected cannot get the DetNet service.
 
 In other words, reserved bandwidth that is not used by a reserved flow is available to best-effort traffic, but not to other reserved flows.
 
 If those conditions are acceptable to this application, then it is suitable to be added to the use cases document.
 
 -- Norm


 
--------------------------------------------------------------------------------



From: [e-mail] [[e-mail]]
 Sent: Monday, July 10, 2017 7:06 PM
 To: Norman Finn
 Cc: [e-mail] [e-mail] [e-mail] [e-mail]
 Subject: 答复: Re: [Detnet] 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt


Hi Norm,

In the case of blockchain application p2mp communication, the highly frequent delivery of the data (transactions, records, etc.) is low speed traffic (in the magnitude of 10-100kbts), so the bandwidth shall not be the dominant latency   contributor. Ensure  the traffic be delivered in a bounded latency, and most important of all to reduce the retransmission (would incur extra latency) with both buffer revservation and PREF, would be quite helpful for the real-time blockchain delivery.

Thanks for your comment.

Daniel

 

 

 

 


 


黄光平 huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P...R.China, 210012 
 M: [phone] 
 E: [e-mail] 
 www.zte.com.cn






 






 



发件人： <[e-mail]>



收件人：黄光平10039714  <[e-mail]>



抄送人： <[e-mail]>  <[e-mail]> <[e-mail]>



日 期 ：2017年07月10日  22:41



主 题 ：Re: [Detnet] 答复: Re:  答复:  Re:  转发:  New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


I read the blockchain draft, and have a very big question about its suitability as a DetNet application:
 
 I see nothing about having a relatively constant bandwidth among the blockchain hosts.  Each DetNet flow has a bandwidth reservation, and unused bandwidth is NOT available to other DetNet flows.  I see nothing in the draft about bandwidth, just words about     low latency and low packet loss.
 
 Conceivably, packet replication and elimination might be of some use, but that could be folded into the application, and existing means of creating multiple distribution trees could be used.
 
 -- Norm


 
--------------------------------------------------------------------------------



From: detnet [[e-mail]] on behalf of [e-mail]  [[e-mail]]
 Sent: Monday, July 03, 2017 5:52 PM
 To: [e-mail]
 Cc: [e-mail] [e-mail] [e-mail]
 Subject: [Detnet] 答复: Re: 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt


Hello Maik,

I would say it is a generic use case related to blockchain-based applications particularly the allied and private blockchain applications which run in a confined network environment.

The network would contribute real-time service for the time-sensitive applications (transaction confirmation, property clarification etc.) with determinstic networking services.

As for intergration between detnet and blockchain, I suppose either the application is detnet aware or the network could be configured to serve the blockchain application flows with detnet services.

Thanks.

Daniel

 

 

 

 


 


黄光平 huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P....R.China, 210012 
 M: [phone] 
 E: [e-mail] 
 www.zte.com.cn






 






 



发件人： <[e-mail]>



收件人：黄光平10039714  <[e-mail]>



抄送人： <[e-mail]>  <[e-mail]>



日 期 ：2017年07月03日  21:30



主 题 ：Re: [Detnet] 答复: Re:  转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


Hello Daniel,



 



Is this a more generic use case (imposing latency, packet loss, …, requirements) or do you envision a tighter integration with block-chain technologies?



 



Thanks, Maik



 




From: detnet <[e-mail]> on behalf of "[e-mail]"   <[e-mail]>
 Date: Monday, 3. July 2017 at 11:13
 To: Patrick Wetterwald <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>,  "[e-mail]"   <detnet@ietf..org>
 Subject: [Detnet] 答复: Re: 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt



 


Hi Patrick, Ethan and all,

Time sensitivity is one of major features of blockchain applications, for example a security  transaction confirmation process is expected to be confirmed and completed as quickly as possible (within microseconds). Apart from the  application-level process     impacting the delivery time, it would be greatly beneficial for the supporting network to treat the blockchain flows with deterministic latency and packet loss guarantees,  because its highly frequent point to multi-point transport  (inherent in blockchain)     in which the wild latency and packet loss from best-effort services contributes significant portion of the service delivery delays.

 

As for specific boundacy of blockchain, the industry has yet to specify and quantify other than expect the network play a role to provide latency and packet loss guarantees.

 

Blockchain extends beyond its original meaning as a technical term to stand for an emerging industry. I agree and am ok if it's called blockchain-based applications.

 

Thanks for your comment.

Daniel

 

 

 


 


黄光平huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P....R.China, 210012 
 M: [phone]
 E: [e-mail]
 www.zte.com.cn






 





 


 



发件人： <[e-mail]>



收件人： <[e-mail]>黄光平10039714



抄送人： <[e-mail]>



日 期 ：2017年07月03日  16:26



主 题 ：Re: [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


Hi Ethan, Daniel,


 


To be completely honest I did not get it. After reading the draft, I do not see any specific related to Deterministic Networking.


Daniel, we probably need more information on the use case. Some questions like the followings will need to be answered:


 


Is there some real-time requirements and impact? (i.e. if a packet is not received in a certain time, how the blockchain application is impacted?)


How do you compute the necessary bandwidth?


Do you have rough number of delay, jitter, packet loss?


How do we know if Detnet is satisfying Blockcahin requirements?


 


Blockchain is a technology not really a use case. So more information is needed.


 


Thanks,


 


Patrick


 


 



From: detnet <[e-mail]> on behalf of "Grossman, Ethan A." <[e-mail]>
 Date: Monday, 3 July 2017 at 05:15
 To: "[e-mail]" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>
 Subject: Re: [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt



 


Exactly, now we are in sync - the addition of this use case to the Use Cases draft would not cause any new asks from DetNet. So now I am just waiting for some comments from at least a couple of people on the list to agree that the  text as given is technically      correct and makes sense to include in the Use Cases draft (or if not, why not). 

Thanks,

Ethan.


 
--------------------------------------------------------------------------------



From: [e-mail] <[e-mail]>
 Sent: Sunday, July 2, 2017 6:39 PM
 To: [e-mail] Grossman, Ethan A.
 Subject: 答复: Re: [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt


 



Hi Ethan,

I realize DetNet would be passive with regard to the specific applications such as blockchain applications and only provide common detnet services. so the it would be ok for blockchain applications (actually also include other       use cases) to ask for deterministic services, such as bounded latency, and packet loss, and the detnet aware network could be configured to provide these services. 

Thank you again for your clarification on this issue.

Daniel Huang

 

 

 

 

 


 


黄光平huangguangping


 


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


 




 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P..R.China, 210012 
 M: [phone] 
 E: [e-mail] 
 www.zte.com.cn







原始邮件


发件人： <[e-mail]>



收件人：黄光平10039714



抄送人： <[e-mail]>



日期：2017年07月02日       10:32



主题：Re:      [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 

Hi Daniel,

OK, so we're clear on L3 multicast. Now I have a question about your statement: 

"DetNet needs  to be designed to recognize the specific traffic from blockchain applications" 

 

Thus far, and as far as I know for the future, a DetNet itself has no way to identify traffic related to a specific  use case or application - it is just providing network services       such as delivering packets, but within specific performance specifications such as bounded latency. Can you please clarify what your expectation is in this regard? 

 

Thanks,

Ethan.

 


 
--------------------------------------------------------------------------------



From: [e-mail] <[e-mail]>
 Sent: Saturday, July 1, 2017 2:41 AM
 To: [e-mail] Grossman, Ethan A.
 Cc: [e-mail]
 Subject: 答复: Re: [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt


 



hello Ethan,

Thanks for your comments. 

As for the L3 multi-cast, I agree that it's already in the use case common theme, what I am trying to emphasize is DetNet needs to be designed to recognize the specific traffic from blockchain applications and thus provides DetNet       services, which are chiefly  L3 multicast-based deterministic servcies.

Thanks again.

Daniel Huang

 

 

 

 


 


黄光平huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P...R.China, 210012 
 M: [phone] 
 E: [e-mail] 
 www.zte.com.cn






 





 



发件人： <[e-mail]>



收件人：黄光平10039714       <[e-mail]>



日期：2017年07月01日       05:44



主题：Re:      [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt




 


Hello Daniel,


 


Thank you for writing up this blockchain use case, and I appreciate your use of the existing DetNet Use Cases draft format for your text. As far as I can see,       the blockchain   application is a valid use case for DetNet, and it is different enough from the other use cases in terms of its application that I it would be interesting to include it in the Use Cases draft.


 


Regarding the ask for “Layer 3 Multicast”, my understanding is that this is already implied by the Use Case Common Theme “L2 and L3 Integration”, which says   the     following:


 


8.1.4.  L2 and L3 Integration


 


   A DetNet network is intended to integrate between Layer 2 (bridged)


   network(s) (e.g.  AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g.


   using IP-based protocols).  One example of this is "making AVB/TSN-


   type deterministic performance available from Layer 3 applications,


   e.g. using RTP".


 


Is that sufficient, or do we need to add something more specific about L3 multicast?


 


Also, before adding it to the Use Cases draft, I would like to see some technical review input from the list members, since I myself am not an expert in the   area     of blockchain.


 


Thanks again,


Ethan.


Ethan Grossman


Editor, DetNet Use Cases Draft


 


From: detnet [mailto:[e-mail]] On Behalf Of [e-mail]
 Sent: Friday, June 30, 2017 1:19 AM
 To: [e-mail]
 Subject: [Detnet] 转发: New Version Notification fordraft-blockchain-as-detnet-use-case-00.txt


 

hi all,

I've submitted a draft to bring blockchain as an use case added to the list, and make detnet aware of its deterministic networking requirements.

any comments are welcome.

 

Thanks & cheers,

Daniel Huang

 

 

 

 

 


 


黄光平huangguangping


 


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


 






 南京市雨花区软件大道50号中兴通讯1号楼 
 R&D Building, ZTE Corporation Software Road No.50, 
 Yuhua District, Nanjing, P..R.China, 210012 
 M: [phone] 
 E: [e-mail]
 www.zte.com.cn







原始邮件



发件人：      <[e-mail]>



收件人：黄光平10039714



日期：2017年06月29日         12:07



主题：New      Version Notification fordraft-blockchain-as-detnet-use-case-00..txt




 



 A new version of I-D, draft-blockchain-as-detnet-use-case-00.txt
 has been successfully submitted by Daniel Huang and posted to the
 IETF repository.
 
 Name:        draft-blockchain-as-detnet-use-case
 Revision:    00
 Title:        Allied and private blockchain as detnet use case
 Document date:    2017-06-28
 Group:        Individual Submission
 Pages:        4
 URL:            https://www.ietf.org/internet-drafts/draft-blockchain-as-detnet-use-case-00.txt
 Status:         https://datatracker.ietf.org/doc/draft-blockchain-as-detnet-use-case/
 Htmlized:       https://tools.ietf.org/html/draft-blockchain-as-detnet-use-case-00
 Htmlized:       https://datatracker.ietf.org/doc/html/draft-blockchain-as-detnet-use-case-00
 
 
 Abstract:
    This draft brings blockchain into the detnet use case list.
    Generally speaking, blockchain is both a technical term and a
    blockchain-based industry, which is spreading into a wide range of
    industries other than the thriving bitcoin.  Blockchain would have to
    require the supporting network offer deterministic networking service
    rather than the ongoing best-effort, because of its inherent p2p and
    frequent multicast working mechanism.
 
    Blockchain working process, its current network mechanism and
    challenges ahead, as well as requirements to detnet will be
    illustrated in the draft.
 
                                                                                   
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 The IETF Secretariat