Repository : ssh://git@diktynna/doc On branches: backup-redmine,main
commit 8dbe48c4e1a141213b5d6455fd1aa6515b3c8a0c Author: Linus Lüssing linus.luessing@c0d3.blue Date: Fri Apr 19 02:03:48 2024 +0000
doc: batman-adv/Multicast-Packet-Type: cleanup: remove "Open Questions" section for multicast packet type
8dbe48c4e1a141213b5d6455fd1aa6515b3c8a0c batman-adv/Multicast-Packet-Type.textile | 55 -------------------------------- 1 file changed, 55 deletions(-)
diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index b5025d0f..28ab7839 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -116,58 +116,3 @@ h2. Limitations If such a limitation is reached then batman-adv will either fall back to multicast via multiple batman-adv unicast packes. Or if that is not possible either, to classic flooding.
* Multicast fanout setting is not considered yet. A multicast payload packet will only use one or no batman-adv multicast packet for now, for reduced complexity. And a batman-adv node would not know how to best split destinations to reduce the number of resplits/retransmissions along the paths / multicast tree. \ No newline at end of file - -h2. Open questions - -h3. -#Num Dests size- - --* 1 or 2 bytes for #Num Dests for Address X?- --** If limit of entries were reached, we could just send another - mcast packet? (~6*256 = 1536). Or do we want to be prepared - for jumbo frames?- - ---- - --> going for 2 bytes / potential jumbo frame support - -h3. -Non ideal splits- - --If a packet with n destinations gets too large for the MTU then batman-adv would/should/could try to split it into m packets with n/3 destinations each. where m <= mcast_fanout.- - --However when splitting like this then such the splitting node does not know the best sorting into these m packets. Another node will likely later need to split again due to different next hops for the destinations in a packet.- - --A batman-adv node currently cannot anticipate this for optimized splitting, as it does not know the full topology. Which would potentially lead to more transmissions than necessary.- - ---- - --> Going for just one multicast packet instead of up to mcast_fanout to start with, for simplicity. - -h3. -Fragmentation / MTUs:- - --On transit a forwarding node might have an interface with a smaller MTU than the node which originated the packet. A node could try to split a packet into multiple packets with less destinations. However if the payload data is larger than the interface MTU already then it would still not fit. And the batman-adv fragmentation code won't be able to look into and split within a multicast packet type header.- - --Workaround A):- - --By default only apply multicast packet type if resulting packet is smaller than 1280 (minimum IPv6 packet size) or even 576 (minimum accepeted IPv4 datagram size?). Maybe add a configuration option, which defaults to 576 bytes? While in practice configuring it to 1280 should usually be fine these days with IPv6 capable networks.- - --Solution B)- - --Later ideally the fragmentation code would be able to split the payload within a multicast packet type, while leaving multicast packet type headers in tact. A node should still forward packets if due to this splitting the mcast-fanout limit were violated, to avoid packet loss.- - ---- - --> Workaround C): We require a 1280 bytes MTU on all hard interfaces and only then set the multicast packet type capability flag. - -h3. -Adding a sequence number? / How to avoid loops with tracker marking later?- - --When later implementing a split control <=> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue:- - --When first a path is marked through the tracker TVLV, then paths change due to OGM updates. And then a tracker packet marks such new paths then the merger of both the old and newly tracker marked paths could create routing loops, as the old path is not automatically invalidated.- - --Solution:- - --Don't mark paths. Instead use the tracker TVLV to fill a cache with the mcast/dests lists and assign a hash to this information. Then later send the multicast data with a TVLV containing only this hash instead of the full mcast/dests list. Therefore a specific list of destinations is still maintained and routing decisions still happen on the go, loopfree, instead of trying to a maintain a loopfree, adjacent multicast routing table.- - ---- - --> Don't add a sequence number, we don't need it now. And a new hashing/caching TVLV described above should work fine later. \ No newline at end of file