Ouroboros Frequently Asked Questions: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 28: | Line 28: | ||
== Can the “forwarding layer” can manage congestion control (instead of the protocol performing flow control)? == | == Can the “forwarding layer” can manage congestion control (instead of the protocol performing flow control)? == | ||
== TCP over TCP is known to perform very badly unless the impact of operating retransmission, reordering, flow control, and congestion control at different layers on top of each other is carefully managed == | == TCP over TCP is known to perform very badly unless the impact of operating retransmission, reordering, flow control, and congestion control at different layers on top of each other is carefully managed. How will Ouroboros overcome this? == | ||
Revision as of 15:53, 16 October 2022
General Remarks
A new model should demonstrate a NEW capability, not just existing examples.
Paper Remarks
Ouroboros claims Unicast and Multicast must be distinct mechanisms. However, these mechanisms interact seamlessly for existing protocols such as IP/ARP and IPv6 (where, in particular, IPv6 packets are transmitted as Ethernet multicast until MAC learning occurs). Isn't this contradictory?
We need to make a distinction here. The claim which we are making is that the process that is doing either multicast or unicast needs to be aware that it is doing so. In the example given, the application uses IPv6, and IPv6 is doing multicast until MAC learning occurs. It is not the application that is using IPv6 that is a multicast application. The IPv6 protocol