simulation: network-spec: more on catchup

Author: Saizan

simulation/docs/network-spec/miniprotocols.tex

@@ -88,20 +88,20 @@ \subsubsection{Description}
 EB-relay rely on \Announcements{} to let consumers know when block bodies
 are available as well. Consumers request IB and EB bodies through the corresponding
 \fetch{} mini protocol (Sec.~\ref{ptcl:fetch}). For EB-relay we specify the \datum{} to be eb-header, by which we mean the constant size part of an Endorse block, while the references (to IBs and EBs) are considered the body.
+\todo{For IB, EB, and Vote the \info{} could actually be unit as we do not need to apply prioritization to headers. However the slot might provide useful filtering, such as avoid downloading any more votes of a pipeline once we have a certificate for a seen EB.}
 
 \begin{table}[h!]
 \begin{tabular}{l l l l l l l l}
 \header{instance} & \header{\BoundedWindow} & \header{\Announcements} & \header{\id{}} & \header{\info{}}
                   & \header{\datum} & \header{\annCond{}} & \header{\ann{}} \\\hline
-Tx-submission & Yes & No & txid & size & tx & N/A & N/A \\
-IB-relay  & No & Yes & hash & slot & ib-header & body available & unit \\
-EB-relay  & No & Yes & hash & slot & eb-header & body available & unit \\
-Vote-relay  & No & No & hash & slot & vote-bundle & N/A & N/A \\
+Tx-submission & Yes & No  & txid & size & tx          & N/A            & N/A \\
+IB-relay      & No  & Yes & hash & slot & ib-header   & body available & unit \\
+EB-relay      & No  & Yes & hash & slot & eb-header   & body available & unit \\
+Vote-relay    & No  & No  & hash & slot & vote-bundle & N/A            & N/A \\
 \end{tabular}
 \caption{\relay{} mini-protocol instances.}
 \label{table:relay-instances}
 \end{table}
-\todo{Review \info{} wrt equivocation.}
 
 \subsection{State machine}
 
@@ -451,13 +451,19 @@ \subsection{Description}
 relevant to reconstruct the ledger state. Additionally it covers
 certified EBs not yet in the chain but which are still recent enough
 for inclusion in a future ranking block, and any blocks they
-reference. This data, together with the base chain, is what is needed
+reference.
+%
+\todo{Unless we specify recent certified EBs are to be offered through
+  the \relay{} protocol still, in which case request
+  \ref{catchup:req:recent-ebs} can be dropped.}
+%
+This data, together with the base chain, is what is needed
 for a node to participate in future pipelines.
 
 The protocol should allow the consumer to divide the requests between
 different producers, and for the producer to have an efficient way to
 retrieve the requested blocks.
-
+%
 The consumer should be able to retrieve the base chain through the
 other mini protocols, and so the EB references within. However, the
 slots of those EBs are unknown, as well as any indirect references.
@@ -467,21 +473,22 @@ \subsection{Description}
 \item[EBs by RB \rbrange{}] given an RB \rbrange{} from its chain, the producer
   should reply with all EBs which are (i) transitively referenced by RBs in that
   range, (ii) not referenced by earlier RBs.
-\item[Recent certified EBs by \slot{} range] given a slot range, the
+\item[Recent certified EBs by \slot{} range]\label{catchup:req:recent-ebs} given a slot range, the
   producer should reply with all certified EBs which are (i) generated
   in the slot range, (ii) not referenced by RBs\footnote{Restriction
   (ii) is to avoid overlap with an RB range query, but could be dropped to save on complexity if not worth the saved bandwidth}. The start of the
   slot range should be no earlier than the oldest slot an EB could be
   generated in and still referenced in a future RB.
+\item[Certificate by EB \point{}] given the \point{} of a certified EB not referenced by the chain, the producer should reply with a certificate for it. Needed for inclusion of the EB into a future RB produced by the consumer.
 \item[IBs by EB \point{}, and \slot{} range] given a \point{} for a
   certified EB, the producer should reply with all the IBs which are (i)
   generated in the given slot range, (ii) directly referenced by
   the EB. The slot range allows for partitioning request about the
   same EB across different peers.
 \end{description}
-\todo{Another option for IBs could be a list of refs and a slot range. The refs come from EB bodies, and the slot range can be calculated from the slot of the EB.}
-\todo{The \emph{IBs by EB \point{}, and \slot{} range} request could be replaced by just a list of IB \point{}s, if IB references are augmented with the slot.}
-\todo{The \emph{EBs by RB \rbrange{}} request could similarly be a list of EB \point{}s instead, if EB refs in RBs and EBs contain slot, and let the consumer discover referenced EBs it needs as it fetches the one it knows about.}
+\todo{The \emph{IBs by EB \point{}, and \slot{} range} request could be replaced by just a list of IB \point{}s, if IB references in EB bodies are augmented with the IB slot. Maybe size of request could become a consideration: by EB \point{} and \slot{} range the request size is $56$ bytes for possibly all the referenced IBs at once, while by IB \point{} the size is $40$ bytes each, and there could be double digits of them. If expect to always fragment requests to just a few IBs at a time the difference is perhaps not important.}
+\todo{The \emph{EBs by RB \rbrange{}} request could similarly be replaced by a list of EB \point{}s,
+if EB references in RBs and EBs are augmented with the EB slot. In this case, the consumer would be in charge of discovering needed referenced EBs as it fetches the ones it knows about.}
 
 \paragraph{Definition} The \catchup{} protocol is defined as a new instance of the \fetch{} protocol. We give the parameters as a grammar
 \[
@@ -491,6 +498,9 @@ \subsection{Description}
        & \mid  & \text{ibs-by-eb-and-slot-range}(\point{},(\slot{},\slot{}))\\
 \body{}_{\catchup{}} & ::= & \text{ib-block}(\text{ib-header},\text{ib-body}) \\
         & \mid & \text{eb-block}(\text{eb-header}, \text{eb-body})\\
+        & \mid & \text{eb-certificate}(\text{certificate})\\
 \end{array}
 \]
-alternatively there could be separate protocols for IB and EB \catchup{}, so that there cannot be a format mismatch between requests and replies.
+alternatively there could be separate mini protocols for IB, EB, and Certificate \catchup{}, so that there cannot be a format mismatch between requests and replies.
+
+\paragraph{Implementation} To fulfill the higher-level freshest-first delivery goal, we might need to stipulate that producers should prioritize serving requests for the \{IB,EB,Vote\}-\relay{} and \{IB,EB\}-\fetch{} mini protocols over requests for \catchup{}.

simulation/docs/network-spec/network-spec.tex

@@ -17,7 +17,7 @@
 \ifbool{isRelease}
     {\usepackage[disable]{todonotes}}
     {\usepackage{todonotes}}
-
+\setuptodonotes{inline}
 \usepackage{amsmath}
 \usepackage{stmaryrd}
 \usepackage{colonequals}