update reviewers and submit time

Author: liutongxuan

rfcs/20200409-fuse_recv.md renamed to rfcs/20200411-fuse_recv.md

@@ -2,10 +2,10 @@
 
 | Status        | (Proposed / Accepted / Implemented / Obsolete)       |
 :-------------- |:---------------------------------------------------- |
-|
 | **Author(s)** | Tongxuan Liu([email protected]) Peng Tao([email protected]) Langshi Chen ([email protected]) |
-| **Sponsor**   | i                                                    |
-| **Updated**   | 2020-04-09                                           |
+| **Reviewers(s)** | Ayush Dubey([email protected]) Jeroen Bédorf([email protected]) Derek Murray([email protected]) Bairen Yi([email protected]) Paul Tucker([email protected]) |
+| **Sponsor**   |                                                      |
+| **Updated**   | 2020-04-11                                           |
 
 ## Objective
 This RFC proposes a new FuseRecv Op which would receive multiple tensors with
@@ -54,8 +54,8 @@ be 1.5-2x timer faster in the parameter-server/worker setup.
 
 ## Design Proposal
 
-![Figure 1: Current graph partition strategy](20200409-fuse_recv/current_graph_partition_strategy.png "Current graph partition strategy")
-![Figure 2: Graph partition strategy with FuseRecv](20200409-fuse_recv/graph_partition_strategy_with_fuse_recv.png "Graph partition strategy with FuseRecv")
+![Figure 1: Current graph partition strategy](20200411-fuse_recv/current_graph_partition_strategy.png "Current graph partition strategy")
+![Figure 2: Graph partition strategy with FuseRecv](20200411-fuse_recv/graph_partition_strategy_with_fuse_recv.png "Graph partition strategy with FuseRecv")
 
 In the original Recv/Send design, each Recv node only receives one tensor
 even if there are Recv Ops that output to the same destination Op. Moreover each
@@ -82,6 +82,7 @@ Pack the N tensors to be sent into a length-N DT_VARIANT vector.
 
 Pros: Reuse currently RPC, avoid potential intricate changes in zero-copy
 response buffer code.
+
 Cons: Introduce memcopy overhead.
 
 #### Fuse the tensors into a single Send/Recv Solution 2 (Derek Murray)
@@ -92,6 +93,7 @@ to reuse some of the graph analysis code
 
 Pros: Reuse currently RPC, avoid potential intricate changes in zero-copy
 response buffer code.
+
 Cons: The fused tensors could be of different types and dynamic shapes,
 which couldn't be handled by this solution.
 
@@ -118,14 +120,15 @@ missing.
 
 Pros: Dynamic fusion in runtime seems get better result, and also brings
 ability to control priority of tensors (which Recv is more important).
+
 Cons: Potential bottleneck of the solution is the time window of ready set.
 For different models it would be much different, manually setting the value
 would be hard. This solution is another good candidate of FuseRecv.
 
 ### Performance Implications
 With a wide and deep model, the number of RPCs calls per step has been reduced
 by 55%, and the overall training throughput has increased by 40%.  
-![Figure 3: performance_result](20200409-fuse_recv/performance_result.png "Performance result")
+![Figure 3: performance_result](20200411-fuse_recv/performance_result.png "Performance result")
 
 ### Dependencies
 * None
@@ -187,7 +190,7 @@ the whole graph, replace Recv ops by FuseRecv ops in the partitioned graphs acco
 to its topology while iteratively searching and fusing potential Recv
 operations. See Figure 4 for the formal algorithm definition.
 
-![Figure 4: fuse_recv_procedure](20200409-fuse_recv/fuse_recv_procedure.png "Fuse Recv Procedure")
+![Figure 4: fuse_recv_procedure](20200411-fuse_recv/fuse_recv_procedure.png "Fuse Recv Procedure")
 
 The procedure RECVFUSE takes two input arguments:  1) the TF computation
 graph g, 2) a Partitioned graph. It is worth noting that the iteration of