RE: [kmip] Groups - kmip-spec-v1.2-csprd01 - streaming-changes.pdf uploa

A single correlation value is specified from first response through all subsequent requests up to the final. The correlation value is created by the server. The consequence of this is that bandwidth utilisation is minimised, and communication delay is maximised. Is this intended? Most streaming network protocols aim to provide the opposite; i.e. maximise bandwidth utilisation, and minimise communications delay.

As KMIP does not support ordered operations, it relies on the transport layer for ordered delivery of requests and responses. This therefore requires that all streaming requests be sent within a single connection-oriented session (as provided within a single TCP connection), and coordinated in the client to ensure that a request is transmitted only after the previous response has been received. In other words, pipelined operations are not possible, and round trip delays will be incurred for each request/response in a stream.

The situation is somewhat worse for asynchronous operations. Is it intended that asynchronous operations be supported in streaming mode? If so, even transport layer ordering will not help, and the only option is for the client to strictly enforce that a request only follow a previous completed response.

In most streaming protocols, a window of outstanding requests is permitted so as to increase bandwidth utilisation, and minimise communication delay. KMIP streaming does the opposite. It works to minimise bandwidth utilisation, and maximise delay.

Personally, I consider this streaming design to be broken now in at least two areas:

1. Requires that each server maintain state for streaming operations, and provides no interoperable, nor KMIP-specified way for managing this state. (Discussed in earlier emails, but accepted by the KMIP TC as the desired way forward.)

2. Streaming performance is, by design, guaranteed to be slow. Each request/response pair will have to wait a round trip delay to ensure correct ordering is maintained.

Regards,

John

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Thursday, 5 June 2014 9:23 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - kmip-spec-v1.2-csprd01 - streaming-changes.pdf uploaded

Submitter's message
Spec changes as per f2f decisions on streaming proposal.
Query for support will be covered in the Query Capabilities proposal.
-- Tim Hudson

Document Name: kmip-spec-v1.2-csprd01 - streaming-changes.pdf

Description
Specification changes to support multi-part (streaming) operations.
Download Latest Revision
Public Download Link

Submitter: Tim Hudson
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2014-06-05 04:22:36

kmip message