Network2/Dynamics: Difference between revisions
< Network2
Jump to navigation
Jump to search
m (New page: Several important numbers that we need to predict and to measure include bandwidth and latency figures: tx == transmit, rx == receive, btx == broadcast btx/tx/rx - ICMPv6+IPv6+phys ...) |
mNo edit summary |
||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Network2 header}} |
|||
Prerequisite concepts: [[Network2/Concept/Bandwidth|bandwidth]], [[Network2/Concept/Latency|latency]], [[Network2/Concept/Jitter|jitter]], [[Network2/Concept/Availability|availability]], [[Network2/Concept/Model|model]], [[Network2/Concept/Unicast|unicast]], [[Network/Concept/Multicast|multicast]], [[Network2/Concept/Broadcast|broadcast]], [[Network2/Concept/Network stack|network stack]] |
|||
First, some baseline analysis: |
|||
Suppose we have a wireless link with capacity C. |
|||
Suppose we have N nodes. |
|||
Suppose each node n wants to maintain f(n) connections. |
|||
If f(n) = 1 then we could allocate up to C/N per connection. |
|||
If f(n) = N then we could allocate up to C/N^2 per connection. |
|||
Instructive values: C=30 Mbps, N=40, f(n)=N ==> 19 Kbps / conn. Conclusion: beware O(N^2) behavior. |
|||
Several important numbers that we need to predict and to measure include bandwidth and latency figures: |
Several important numbers that we need to predict and to measure include bandwidth and latency figures: |
||
| Line 18: | Line 31: | ||
L2TP+IPsec+IPv4 -- raccoon, isakmpd, openswan, etc. |
L2TP+IPsec+IPv4 -- raccoon, isakmpd, openswan, etc. |
||
UDP+IPv4 -- teredo |
UDP+IPv4 -- teredo |
||
Baseline overheads: |
|||
[http://en.wikipedia.org/wiki/Ethernet#Ethernet_frames Ethernet]: 18 |
|||
[http://en.wikipedia.org/wiki/IPv4#Packet_structure IPv4]: 20 + options |
|||
[http://en.wikipedia.org/wiki/IPv6_packet IPv6]: 40 + options |
|||
[http://en.wikipedia.org/wiki/ICMPv6#Packet_format ICMPv6]: 4 |
|||
[http://tools.ietf.org/html/rfc4861#page-18 ICMPv6 RA]: 16 + prefix+{32} + mtu?{8} |
|||
[http://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure UDP]: 4 |
|||
[http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure TCP]: 20 + options? |
|||
[http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record_protocol TLS]: 5 + mac?{16,20,32} + pad?{4,8,16} |
|||
[http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages D-Bus]: 12 + type-array |
|||
[http://xmpp.org/extensions/xep-0045.html#message XMPP MUC]: 50 + jids |
|||
Latest revision as of 20:14, 29 August 2010
Prerequisite concepts: bandwidth, latency, jitter, availability, model, unicast, multicast, broadcast, network stack
First, some baseline analysis:
Suppose we have a wireless link with capacity C. Suppose we have N nodes. Suppose each node n wants to maintain f(n) connections. If f(n) = 1 then we could allocate up to C/N per connection. If f(n) = N then we could allocate up to C/N^2 per connection. Instructive values: C=30 Mbps, N=40, f(n)=N ==> 19 Kbps / conn. Conclusion: beware O(N^2) behavior.
Several important numbers that we need to predict and to measure include bandwidth and latency figures:
tx == transmit, rx == receive, btx == broadcast btx/tx/rx - ICMPv6+IPv6+phys - router discovery (RD) btx/rx - ICMPv6+IPv6+phys - duplicate address detection (DAD) tx/rx - ICMPv6+IPv6+phys - NS neighbor discovery (ND) tx/rx - UDP+IPv6+phys - DNS query tx/rx - JSON+SSH+TCP+IPv6+phys - DNS update where "phys" describes the equations' dependence on the "physical" layer's frame overhead and MTU notable "phys" layers: Ethernet -- ad-hoc wifi, infra wifi, 802.11s mesh, switch, hub TLS+UDP+IPv4 -- openvpn L2TP+IPsec+IPv4 -- raccoon, isakmpd, openswan, etc. UDP+IPv4 -- teredo
Baseline overheads:
Ethernet: 18
IPv4: 20 + options IPv6: 40 + options
ICMPv6: 4 ICMPv6 RA: 16 + prefix+{32} + mtu?{8}
UDP: 4 TCP: 20 + options?
TLS: 5 + mac?{16,20,32} + pad?{4,8,16} D-Bus: 12 + type-array XMPP MUC: 50 + jids