[tsvwg] Re: Seeking Feedback on DACP(Data Access and Collaboration Protocol)

[Ingemar Johansson S <[e-mail]>]

Hi
Thanks for the clarification, now that I re-read the intro I realize that my question was a bit out in the blue, sorry for that. 
As I am a bit of the occasional IETFer, I don’t have any clear guidance how to advance this in IETF

In general, there are some rough requirements for having a draft accepted as  a WG document. The first is to get sufficient support in the working group, I’d suggest that you try and request a slot (10-15 minutes?)  to present this at the next IETF meeting, the email to the chairs is [e-mail] <mailto:[e-mail]>   . 
In addition a proofpoint of existing implementation is good, seems to me that you appear to have it already.

If it is about leveraging on QUIC then perhaps the work on RTP over QUIC (https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-over-quic-14.html ) can give some ideas how to  .


Regards
/Ingemar

 

From: [e-mail] <[e-mail]> 
Sent: Monday, 13 October 2025 04:57
To: Ingemar Johansson S <[e-mail]>; tsvwg <[e-mail]>
Cc: bluejoe <[e-mail]>; zjcheng <[e-mail]>
Subject: Re: [tsvwg] Re: Seeking Feedback on DACP(Data Access and Collaboration Protocol)

 

	
Du får inte ofta e-post från [e-mail] <mailto:[e-mail]> . Läs om varför det här är viktigt <https://aka.ms/LearnAboutSenderIdentification>  

	

Hi Ingemar,

Thank you for taking the time to review the draft and for your excellent question. I’d like to expalin how DACP and QUIC relate to each other. 

 

The key distinction is that DACP’s core functionality is application-layer (defining the SDF model, operations, and provenance), whereas QUIC is a transport-layer protocol. DACP is build on Apache Arrow Flight, which uses the Arrow columnar memory format for its payload. This enables zero-copy data transfer and is highly specialized for data analytics workloads. QUIC provides generic, multiple, independent streams, but it doesn't dictate the format of the data carried within those streams.

Our intention is absolutely to leverage on QUIC. DACP is designed to run on top of the Arrow Flight and gRPC frameworks. As gRPC support for HTTP/3 (which uses QUIC) matures, the intended stack is indeed:

DACP -> Arrow Flight -> gRPC -> HTTP/3 -> QUIC

In this stack, DACP would automatically inherit all the benefits of QUIC.

I hope this clarifies the relationship between DACP and QUIC. I greatly appreciate you raising this point, and I will consider adding a note to the draft.

Best regards,

Xiaojie Zhu

(on behalf of the authors)

 

  _____  

[e-mail] <mailto:[e-mail]> 

 

From: Ingemar Johansson S <mailto:ingemar.s.johansson=[e-mail]> 

Date: 2025-10-10 17:18

To: [e-mail] <mailto:[e-mail]> ; tsvwg <mailto:[e-mail]> 

CC: bluejoe <mailto:[e-mail]> ; zjcheng <mailto:[e-mail]> 

Subject: [tsvwg] Re: Seeking Feedback on DACP(Data Access and Collaboration Protocol)

Hi

I only skimmed through the draft. What I wonder in general is if not standardized and implemented protocols like QUIC would be a solution ?, or of you could leverage on QUIC and propose additions to it in case there are special needs that are not addressed by the QUIC protocol suite yet?.

 

Regards

/Ingemar

 

From: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 
Sent: Friday, 10 October 2025 10:23
To: tsvwg <[e-mail] <mailto:[e-mail]> >
Cc: bluejoe <[e-mail] <mailto:[e-mail]> >; zjcheng <[e-mail] <mailto:[e-mail]> >
Subject: [tsvwg] Seeking Feedback on DACP(Data Access and Collaboration Protocol)

 

	
Du får inte ofta e-post från [e-mail] <mailto:[e-mail]> . Läs om varför det här är viktigt <https://aka.ms/LearnAboutSenderIdentification>  

	

Dear TSVWG Chairs and Members,

 

We are writing to propose our new Internet-Draft, DACP (Data Access and Collaboration Protocol), for consideration and potential adoption by the Transport Area Working Group (TSVWG).

 

The Internet-Draft is available here:

https://datatracker.ietf.org/doc/draft-shenzhihong-dacp/ <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-shenzhihong-dacp%2F&data=05%7C02%7Cingemar.s.johansson%40ericsson.com%7C0339f73151fe4dc9544008de0a044838%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638959210686370978%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IlNHFybpR2apfiypBb%2FJ5INjlyQz1C%2Fo25wTYsyFgcE%3D&reserved=0> 

 

What is DACP?

DACP is a communication protocol designed to support cross-node, cross-process data access, primarily for scientific and distributed computing environments. Modern data processing, particularly in scientific and distributed computing, requires unified, low-latency data access across diverse nodes and processes. However, the fragmented and heterogeneous nature of scientific data currently hinders effective data sharing and collaboration. To address this, DACP introduces a high-performance solution built upon Apache Arrow Flight, creating a zero-copy, columnar streaming framework that unifies access to both structured and unstructured data. DACP’s goal is to provide a secure, auditable, and low-latency data channel that finally enables the efficient sharing and collaborative processing of scientific data.

 

Our primary question for the group is whether the problem that DACP addresses falls within the scope and interest of the TSVWG. We would be very grateful for your expert opinion on this. If you feel this work is not a good fit, any suggestion for a more appropriate working group would be highly appreciated.

 

Thank you for your time and expertise.

 

Best regards,  

Xiaojie Zhu

(on behalf of the authors)

 


  _____  


[e-mail] <mailto:[e-mail]>