In section 3.3.4, on page 24, the old number of 600GB is still used.

Also, what's the approximate size of each message?

Thanks for finding that other reference. I've updated it.

The minimum Alert size is 82 KB, from adding up the entries in the DPDD and determining the number of historical DIASource records per Alert based on LSE-81. Maria reportedly had 135 KB per Alert without history, but I'm not certain that was measured correctly, and I think it involved a very inefficient encoding of some metadata. So I think we can get substantially smaller.

I have already provided my input to this, so no further comments from me.

I'm not comfortable updating the alert sizing to these values without a demonstrated serialization. The Avro encoding is our implementation baseline and undergirded the completion of the LDM-503-5 milestone. At this point we can make estimates at higher fidelity than simply counting fields and I think it's worth taking the time to do so (and identify where inefficiencies exist and fix them). I'm happy to take this on.

I also think we need to present more nuance about when the clock stops on OTT1. Summarizing our email discussion, we are in agreement that "packet arrival at the broker" is not workable because of potential network and broker latencies. However I am not convinced that "making the alert available in the queue at NCSA" is satisfactory as an endpoint because it does not account for even ideal transit time out of NCSA.

I haven't had time to work on a measurement of Avro sizing. If Eric Bellm can do so, that would be great.

I'm not sure there is such a thing as "ideal transit time" out of NCSA unless we also define an "ideal broker" at some physical and network location. Availability at the NCSA network endpoint would seem to be the best that can be measured and managed. If we want to reserve some additional budget for (N_bytes / nominal_bandwidth), we could, but that's not really different from subtracting a few seconds from OTT1 with the network-endpoint definition.

Kian-Tat Lim: I'll work on an improved estimate of the Avro sizing.

I take your point that we can only effectively measure (and control) packet availability at the NCSA endpoint, so I agree we should do so. But I do think we have to allocate (N_bytes / nominal_bandwidth) in OTT1--otherwise we could claim success even if there was no pipe out of NCSA at all

Created https://jira.lsstcorp.org/browse/DM-16280 for the estimation.

This RFC arose from a DMLT action of 2018-10-08 on Jeff Kantor & Kian-Tat Lim to (among other things) “... to document the available bandwidth for ... alert streams”.

Understanding the size of an individual alert stream may be a necessary prerequisite for understanding how many streams some given bandwidth can support — and, arguably, may be useful in reasoning about how much total bandwidth is necessary — but it's not obvious that this RFC as written actually addresses the action requested. What is the plan for baselining a total alert stream bandwidth?

As I understood this, there are two tasks to complete this:

Eric and K-T need to agree on a sizing for each stream

NCSA needs to provide an analysis of ALL LDF outbound traffic rates, including alerts

In the interim, we decided that we could a priori allocate 10 Gbps to alert streams, irrespective of the above.

What's the status of this RFC?

Quantitative estimates are complete (DM-16280), so I think it's just to Kian-Tat Lim to update the documents?

I think that this RFC has run its course since it's not requesting approval for an update of LDM-151, it seems to be requesting that we at some point update LDM-151. Can we mark it as implemented based on DM-16280 being done and then when Kian-Tat Lim does the update to LDM-151 that would become another RFC?

Per my comment above, we still haven't adequately addressed the todo list item which this RFC is (supposedly) in response to. Please don't close this RFC until either the full todo list item has been addressed or some other ticket has been filed to capture the action of documenting available bandwidth.

My plan is to modify LDM-151 with the per-stream bandwidth and LDM-148 with the total available baseline outbound alert network bandwidth (in text) and per-stream bandwidth (in figure). This RFC will then morph into proposing those two new document versions for CCB acceptance.

I'm hoping to complete those modifications and publish new versions in DocuShare later this afternoon.

New non-preferred draft versions of LDM-148 and LDM-151 have been uploaded to DocuShare.

The DM-CCB is requested to approve these changes to LDM-148 and LDM-151.