Just a question :-)

[acmacm]

I think this is just the initial steps - and I never read go before, so... In the final section:

    src := int32(tcp.SrcPort)
    dst := int32(tcp.DstPort)
    if dst == ofport {
        packets_in[src] = time.Now().UnixNano()
    }

    if src == ofport {
        latency := time.Now().UnixNano() - packets_in[dst]
        h.Add(float64(latency / 1000000.0))

you use the switch port as an index, and match the packet_in time to the response packet and calculate latency. So, do you assume only one packet from the switch is being served at a time? Or, will the match find the first packet in the packet_in list? And what if there is no response packet from the controller (lost packet_in)?

[anastop]

That's a good question.

Currently, the latte matching logic works for traffic patterns where there is at most one Packet_In in flight from every switch. MTCbench working in "latency" mode is such a case, where switches send Packet_In's and wait for responses before sending the next ones. So, in it's current form, latte tracks the arrival of incoming Packet_In's, indexing them based on the switch port, knowing that no other Packet_In from the same port will come in the meantime and overwrite the timestamp of the Packet_In that's already in and being processed by the controller. This is quite simplistic, but to get an idea of its efficiency and overhead I think it's a good starting point.

For traffic that does not follow this pattern and out-of-order replies are possible, we have to inspect deeper in each Packet_In and find fields against we will match it with a Flow_Mod (e.g. src_mac, dst_mac). I am currently investigating this.

As regards lost Packet_In's, there is no code to track them yet but it should be relatively simple to implement: the idea is to declare a packet as lost, either when its Flow_Mod is too late (based on a Tmax value), or when the same Packet_In has arrived in the meantime as a result of a retransmission from the switch but has found the previous one still in its bucket.

[acmacm]

Hi Nikos,

When I searched this time, I found a OF controller which is written in Go,

https://github.com/hkwi/gopenflow

this should have code that will help, but I haven’t located the specific routine in the codebase yet, and I’m running out of time today – sorry! Al

From: Nikos Anastopoulos [mailto:notifications@github.com] Sent: Friday, April 15, 2016 4:17 AM To: anastop/latte Cc: MORTON, ALFRED C (AL) Subject: Re: [anastop/latte] Just a question :-) (#1)

That's a good question.

Currently, the latte matching logic works for traffic patterns where there is at most one Packet_In in flight from every switch. MTCbench working in "latency" mode is such a case, where switches send Packet_In's and wait for responses before sending the next ones. So, in it's current form, latte tracks the arrival of incoming Packet_In's, indexing them based on the switch port, knowing that no other Packet_In from the same port will come in the meantime and overwrite the timestamp of the Packet_In that's already in and being processed by the controller. This is quite simplistic, but to get an idea of its efficiency and overhead I think it's a good starting point.

For traffic that does not follow this pattern and out-of-order replies are possible, we have to inspect deeper in each Packet_In and find fields against we will match it with a Flow_Mod (e.g. src_mac, dst_mac). I am currently investigating this.

As regards lost Packet_In's, there is no code to track them yet but it should be relatively simple to implement: the idea is to declare a packet as lost, either when its Flow_Mod is too late (based on a Tmax value), or when the same Packet_In has arrived in the meantime as a result of a retransmission from the switch but has found the previous one still in its bucket.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHubhttps://github.com/anastop/latte/issues/1#issuecomment-210353426

[anastop]

Thanks Al, I will check it out! There is also a pull request for OpenFlow in gopacket, it's still open due to conflicts with the rest code base but could be useful, as well: https://github.com/google/gopacket/pull/93/files .