How to describe the path of a multicast stream in JSON file?

[spzhan]

I want to calculate the delay of some multicast streams, but I’m not sure how to describe the path of the multicast stream in JSON file. If I use XML as input file, I can describe the multicast path through multiple target elements, but there seems to be a problem with XML, which is that it cannot set different service curve for the ports at both ends of the link.

If there is a multicast stream and different service curve needs to be set for the servers at both ends of the link, what should I do？

Looking forward to your reply. Thank you!

spzhan

[adfeel220]

Hello, defining multicast flows in a JSON file is unfortunately not supported for the moment. If I understand your question correctly, you may try to define different service curves on individual links. An example is as follows

<link from="src0" to="s0" fromPort="o0" toPort="i0"
      service-latency="1us" service-rate="100Gbps" transmission-capacity="200Gbps"
      name="src_sw_0"/>

In this way, the service curve explicitly defined on each link is taken with a higher priority. You should be able to write almost equivalent format as in a JSON file while preserving the multicast functionality.

Feel free to reach out to me if there's still any question.

Chun-Tso

[spzhan]

Thank you very much for your reply. I may not have expressed myself clearly. My main problem is that different curves need to be set for the ports at both ends of the same link, for example:

<link from=“e0” to=“s0” fromPort=“0” toPort=“0” name=“lk:e0_0-s0_0” service-latency=“50us” service-rate=“1Mbps” transmission-capacity=“100Mbps”/> 
<link from=“s0” to=“e0” fromPort=“0” toPort=“0” name=“lk:s0_0-e0_0” service-latency=“5us” service-rate=“10Mbps” transmission-capacity=“100Mbps”/>

It is possible that the ports S0-0 and e0-0 at both ends of the same link have set different WRR weights, so their service curves are different, for example, s0-0 = 10Mbps, while the reverse e0-0 = 1Mbps But if I use the above input, in xTFA, the parameters of the later link will replace the parameters of the previous link.

Simple test data, input xml:

<?xml version="1.0" encoding="UTF-8"?>

<elements>
    <network name="toy_x" technology="FIFO+IS" minimum-packet-size="64B" converted="toy_x.json"/>
    <station name="e0" service-latency="1ns" service-rate="100Mbps" transmission-capacity="100Mbps"/>
    <station name="e1" service-latency="1ns" service-rate="100Mbps" transmission-capacity="100Mbps"/>
    <switch name="s0" service-latency="1ns" service-rate="100Mbps" transmission-capacity="100Mbps"/>
    <switch name="s1" service-latency="1ns" service-rate="100Mbps" transmission-capacity="100Mbps"/>
    <link from="e0" to="s0" fromPort="0" toPort="0" name="lk:e0_0-s0_0" service-latency="50us" service-rate="1Mbps" transmission-capacity="100Mbps"/>
    <link from="s0" to="e0" fromPort="0" toPort="0" name="lk:s0_0-e0_0" service-latency="5us" service-rate="10Mbps" transmission-capacity="100Mbps"/>
    <link from="s1" to="e1" fromPort="1" toPort="0" name="lk:s1_1-e1_0" service-latency="50us" service-rate="1Mbps" transmission-capacity="100Mbps"/>
    <link from="e1" to="s1" fromPort="0" toPort="1" name="lk:e1_0-s1_1" service-latency="5us" service-rate="10Mbps" transmission-capacity="100Mbps"/>
    <link from="s0" to="s1" fromPort="2" toPort="2" name="lk:s0_2-s1_2" service-latency="50us" service-rate="1Mbps" transmission-capacity="100Mbps"/>
    <link from="s1" to="s0" fromPort="2" toPort="2" name="lk:s1_2-s0_2" service-latency="5us" service-rate="10Mbps" transmission-capacity="100Mbps"/>

    <flow name="f0" arrival-curve="leaky-bucket" lb-burst="80.0b" lb-rate="10000.0" source="e0" maximum-packet-size="100B" minimum-packet-size="32.0b">>
        <target>
            <path node="s0"/>
            <path node="s1"/>
            <path node="e1"/>
        </target>       
    </flow>

</elements>

The result is:

flow_e2e_delay”: { “f0”: { “Panco_TFA”: 393.913, “Panco_SFA”: 230.0, “Panco_PLP”: 230.0, “Panco_ELP”: 230.0, “DNC_TFA”: 391.5, “DNC_SFA”: 230.0, “DNC_PMOO”: 230.0, “DNC_TMA”: 230.0, “DNC_LUDB”: 230.0, “xTFA_TFA”: 37.43583476259417 }

From this result, the calculation result of xTFA seems to be incorrect, because it uses 10Mbps as the service curve to calculate instead of 1Mbps. But I also want to use the xTFA algorithm, because only xTFA can better support multicast streams, so I wonder if I can complete the input of multicast streams in json, Because json can directly define the Output Port service curve, without worrying about the link.

I hope I have made my question clear and look forward to your reply.Thank you!

spzhan

[adfeel220]

@spzhan Thank you for providing the detailed information. I believe it's a bug in our xTFA implementation. We will try to solve it soon. Meanwhile, I will put the support of multicast flow in JSON format as a pending task but it will probably not be finished very soon.

@LudoInSpace Can you help me verify the problem? I did a quick check and I believe the problem is at xtfa/networks.py, line 161 & 171. Because the Wopanet reader only adds edges by their name of physical device instead of output port names, it only registers the first link definition and ignores the rest. Also, at line 161 the undirected graph also eliminates the possibility of different link characteristics on both directions.

In the above example, I found the registered physical topology only have 4 nodes and 3 edges. I believe this is the problem but can you please check it as well? If you don't have time I can try to fix it later if you prefer.

[spzhan]

Yes, fixing the bug in xTFA should be a more direct solution. Looking forward to your update.

[LudoInSpace]

Hello, It's related to what we discussed last Friday.

Originally, WopanetXML format that is used by xTFA defines a link as a bi-directionnal full-duplex link. The rational for this is historical: the tool Wopanet is used by industrials (more focused on the physical topology than on the graph of output port), and mostly for FIFO, symmetrical networks (such as AFDX).

Due to miscommunication (and a lack of documentation to WopanetXML), Saihu actually interprets each link as a unidirectional link associated to a unique output port, which is incompatible with the way xTFA reads them.

I don't intend to change the meaning of link in WopanetXML because:

• of compatibility requirements with Wopanet
• because I like having a way of defining a physical topology instead of a graph of output ports. In my mind, a physical topology is an non-directed graph where an edge is a full-duplex link.

So my short-term plan is: 1/ Me: add option tags inside the definition of a link to allow for specifying the service curve of each side of the link. This is the fastest solution that targets people that use WopanetXML and xTFA directly.

But a more complete fix, allowing for consistency across Saihu subtools would be to also do: 2/ Together: define a format for multicast flows inside JSON (ie output-port graph description). 3/ Update Panco, DNC, etc. interfaces to allow for minimal support of multicast flows described in JSON, for example, creating one Panco flow for each target of a JSON flow and recording the maximum delay bounds across all Panco's flow for one multicast JSON flow. 4/ Me: add support in xTFA to directly read JSON files (ie, output-port graph description) 5/ Update the translator JSON to XML and XML to JSON to take into account the changes of both 1/ and 2/. 6/ Once 4/ is done, Update the interface to xTFA to directly provide the JSON to xTFA if the enduser provided a JSON. 7/ Update documentation of both XML (for differentiated service) and JSON (for multicast) formats .

I'll work on 1/ (provides immediate fix to @spzhan) and 4/ probably during this Christmas break. I'll open empty PRs on 1/ and 4/ to indicate that I'm working on it and avoid parallel work. Then I propose anyone interested to participate on other items can do the same.

Maybe in the following of the discussion on this issue could we decide for 2/ ? That is decide on a way to describe multicast flows in JSON ?

Ludovic

[adfeel220]

Hi, thanks @LudoInSpace ! I will also try to work on the integration of multicast flows for JSON format. BTW, I invite you as the collaborator of this repo, maybe that can help your workflow.

[LudoInSpace]

Hey, because the consistency JSON vs XML and the translators will be broken as long as we have not implemented all the steps outlined above, I suggest we create an experimental branch, experimental-multicast, to gradually add the changes we discussed above towards full multicast support. I already have #9 that solves the issue mentioned by @spzhan (reviews appreciated) and that I will merge on the experimental branch tomorrow if no objection. Then, @spzhan will be able to switch to this experimental branch to solve their issue, keeping in mind that JSON-XML consistency will be lost (was arguably already lost).

Later when multicast support is fully ready, we can merge the experimental branch into main. Ludovic

[spzhan]

thank you @LudoInSpace ! I will try the experimental branch later, looking forward to the fully multicast function.

[adfeel220]

I just opened PR #12 which should allow the JSON support of multicast flows. It is a quick temporary solution to the suggested steps 2, 3, 5 by @LudoInSpace, feel free to give feedback on it. I will merge it into the main branch soon after I finish some tests.

TL;DR

You can now define multicast flows in the JSON format and convert it to XML

Details

• To define it, please refer to the updated manual (README) or the new example file (example/demo.json)
• The conversion between the two formats is possible with the built-in tool
• For tools other than xTFA that don't have built-in support for multicast flows: the way Saihu treats it now is to separate the paths as individual flows having the same arrival curve. Then, the presented delay bound is the maximum delay among all the paths of the same flow.