Symmetric vs Asymmetric routing (#3)

* Symmetric vs Asymmetric routing

The sentence edited is using symmetric/asymmetric in the wrong order, hence this PR is fixing that. Furthermore, IIRC, asymmetric is going to be implemented first, is that correct?

* Update rfcBBL102.md

* Update rfcBBL102.md

Co-authored-by: Alfonso de la Rocha <alfonso.rocha@protocol.ai>

Author: yiannisbot

beyond-bitswap/rfc/rfcBBL102.md

@@ -26,7 +26,7 @@ The idea is to include a TTL to WANT messages. That way instead of forwarding WA
 
     -   Asymmetric routing: Messages do not follow the same path followed by the WANT message, and responses are directly forwarded to its original requestor. In this alternative, nodes follow a "fire-and-forget approach" where intermediate nodes only act as relays and don't track the status of sessions, the receiving node X-hops away answer the requestor node directly, and the only one tracking the state of the session is the originating peer (and maybe the directly connected peers while the session has not been canceled, so that if they see any of the requested blocks it can notify its discovery). When implementing this approach we have to also bear in mind that establishing connections is an expensive process so in order for this approach to be efficient we should evaluate when it is worth for nodes to open a dedicated connection to forward messages back to the original requestor.
 
-Initially, the protocol will be designed using symmetric routing, and will explore other routing alternatives in the future work. When exploring asymmetric routing we need to bear in mind that according to IPFS values, nodes shouldn't push content to other peers that haven't requested it.
+Initially, the protocol will be designed using symmetric routing, and will explore other routing alternatives in the future work. When exploring symmetric routing we need to bear in mind that according to IPFS values, nodes shouldn't push content to other peers that haven't requested it.
 
 Again, this proposal should include schemes to avoid flooding attacks and the forgery of responses. It may be sensible to include networking information also in the request to allow easy discovery to forward responses X-hop away.