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

[Mirja Kuehlewind <[e-mail]>]

Hi Xiaojie,

thanks for bring you work to the IETF and thanks for the additional explanation below. I wasn’t able to read the draft fully yet but looking at the protocol stack below, I think that tsvwg is actually not the right group. This proposal probably belongs in the ART area and I recommend you to ask for a presentation slot in the dispatch group and/or reach out to ART area directors for further advise.

Also, if you have any further question on the IETF process, feel free to directly send me an email. Happy to help or try to redirect you to the right person!

Mirja



From: "[e-mail]" <[e-mail]>
Date: Monday, 13. October 2025 at 04:57
To: Ingemar Johansson S <ingemar.s.johansson=[e-mail]>, tsvwg <[e-mail]>
Cc: bluejoe <[e-mail]>, zjcheng <[e-mail]>
Subject: [tsvwg] Re: Seeking Feedback on DACP(Data Access and Collaboration Protocol)

You don't often get email from [e-mail]. Learn why this is important<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]

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] <[e-mail]>
Sent: Friday, 10 October 2025 10:23
To: tsvwg <[e-mail]>
Cc: bluejoe <[e-mail]>; zjcheng <[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/

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]>