OTLP exporter concurrent sending requirements

[aabmass]

What are you trying to achieve?
Implementing OTLP exporter concurrent sending in the python SDK (open-telemetry/opentelemetry-python#1108), as required in the spec matrix. Relevant part of specification: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#otlpgrpc-concurrent-requests

What did you expect to see?
Implementation details may be underspecified.

• The number of concurrent requests SHOULD be configurable.

  The maximum achievable throughput ismax_concurrent_requests * max_request_size / (network_latency + server_response_time).

  • The spec does not give defaults for max_concurrent_requests and max_request_size.
  • Configuration parameters are not specified in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#configuration-options

• the client implementation SHOULD expose an option to
  turn on and off the waiting during shutdown.

  • gRPC unary calls wait for a response. gRPC doesn't seem to provide "fire and forget" (Support fire-and-forget RPC invocation? grpc/grpc#2147)
  • Configuration parameter for this is not specified in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#configuration-options
  • Should the client return SUCCESS immediately if not waiting for ack?

Additional context.
Can we mark this optional in the spec matrix? Is it required for 1.0?

[jmacd]

The metrics data model should, I believe, explicitly state that OTLP data points may be written out of order. Without such a statement, OTLP exporters will have to be more complicated. As noted in this draft about the metrics data model, https://docs.google.com/document/d/1rncVUp_nzAhA39trS1hUFinIlO01jf7KBbuIRhqMI7Y/edit#, there will come a point where OTLP data is translated into PRW, for example, at which point data will have to have be ordered. This will be one of the challenges for that exporter inside the collector, but it's not a problem for the SDK itself.