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

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:  [mailto:]
On Behalf Of Tim Hudson

Sent: Thursday, 5 June 2014 9:23 PM

To: 

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