cfrg/draft-irtf-cfrg-vdaf

Consider replacing ping_pong_* with input_share_to_out_share_*

Closed this issue · 2 comments

The functions begin with ping_pong is specific to the topology, the rest of VDAF interface specifies the purpose of each step, which I think makes more sense.

To make it consistent with VDAF.measure_to_input_shares, VDAF.out_shares_to_agg_share, VDAF.agg_shares_to_result, I think we should replace ping_pong with input_share_to_out_share. For e.g.

input_share_to_out_share_start
input_share_to_out_share_req
input_share_to_out_share_resp

Related, I have a few other thoughts about the ping pong steps.

  • Intuitively, I would think ping_pong_start transition the state to Start, but it actually transits to either Continue or Rejected.
  • Do we want to separate ping_pong_req and ping_pong_resp? they are essentially the same state transition step on Continue state, just react differently on input.

Bear in mind the purpose of this new text is to map VDAF preparation to a concrete communication pattern, which we're currently calling "ping ponging" (for lack of a better term). This is not the only valid communication pattern, so were we to make this change, I'd think we'd still want to make it specific to the communication pattern in DAP somehow.

Related, I have a few other thoughts about the ping pong steps.

* Intuitively, I would think ping_pong_start transition the state to Start, but it actually transits to either Continue or Rejected.

I see what you're saying, but there is really no difference between Continued from ping_pong_start and Continued from ping_pong_req or pring_pong_resp: the same transition rules apply no matter how you got there.

Maybe renaming would be helpful? Perhaps:

  • Start -> Ready
  • Continued -> Waiting
* Do we want to separate `ping_pong_req` and `ping_pong_resp`? they are essentially the same state transition step on Continue state, just react differently on input.

Yes because the handling of inbound is different. The logic that is identical is already encapsulated by ping_pong_transition. I don't see a way to refactor further but you're welcome to give it a shot!

@wangshan can you take another look at this issue and let us know if there's anything else to do here?