Transparent Redirections in Content Delivery Networks

Round 1

Reviewer 1 Report

The authors of this paper propose an SDN-based redirection mechanism that hands-off TCP connections in a transparent way to end-points. The proposed mechanism can be useful in a variety of scenarios such as Content Delivery Networks and Load Balancing mechanisms. This an extension of a previous TSP 2019 conference paper.

 

The proposal is evaluated with the aid of multiple software-defined networking tools, such as OpenFlow, Mininet, and Open vSwitch. The proposed TCP session handoff procedure is tested on a couple of scenarios, comparing 302 redirections with the proposed mechanism. A very nice feature of the contribution is the fact that the authors make available a considerable amount of the modules they build, which goes perfectly with the philosophy of Mininet and OpenFlow experimentations that promote reproducible simulations. Even if the reported results show that 302 redirections outperform the proposal regarding the incurred delay, they are promising since the controller is a module subject to be improved. Thus, the most attractive feature of the proposal is its transparency to end-points, making it very interesting for a large set of potential scenarios.

 

The paper is well structured and flows well; moreover, it is well written. However, it can be still improved by correcting several grammar errors and typos. Finally, starting with an Introduction section labeled with "0" is strange, so this can be easily corrected.

Author Response

Dear reviewer, 

Thank you for your review on our proposed article. 

Regarding note:
"The paper is well structured and flows well; moreover, it is well written. However, it can be still improved by correcting several grammar errors and typos. Finally, starting with an Introduction section labeled with "0" is strange, so this can be easily corrected."

The article went through grammar correction. The numbering of the chapters is starting at 1 in the revised version.

Best regards,

Tomas Boros

Reviewer 2 Report

This paper shows the TCP redirection scheme using SDN.

It is said to utilize existing 2 TCP connections, i.e., one between client and request router as well as the other between request router and surrogate router. However, it is said that the data stream from surrogate server is directly forwarded toward a client. From such configuration, the authors are required that  the proposed scheme may be applied to https session.Moreover, it is required why the data stream from surrogate server uses a direct connection toward a client. Generally, the performance of TCP is dependent on rtt latency and rwnd/cwnd. If the intermediate, request router, considers only sequence/acknowledgement number, the proposed configuration is not sure how much the performance gain gets.

 

 

 

Author Response

Dear reviewer,

thank you for your article review.

Please let us give you some detailed information to your notes:

- "However, it is said that the data stream from surrogate server is directly forwarded toward a client. From such configuration, the authors are required that the proposed scheme may be applied to https session.":

In the conclusions (last sentence) it is stated that, the possibility of using secured TLS based TCP sessions should be elaborated in the future. Currently TLS based HTTPS sessions are not supported by the proposed design.

- "Moreover, it is required why the data stream from surrogate server uses a direct connection toward a client."
Transferring the content from the surrogate server directly to the client is more effective, as it does not have to pass the request router. Surrogate servers in CDN are chosen based on the client's location. In most of the scenarios, the surrogate servers are closer to the clients compared to the request routers.

- "Generally, the performance of TCP is dependent on rtt latency and rwnd/cwnd. If the intermediate, request router, considers only sequence/acknowledgement number, the proposed configuration is not sure how much the performance gain gets."
In general, the performance is indeed dependent on RTT and RWND and CWND. These parameters (RWND and CWND) are, however, managed by the endpoints. After a successful TCP session handoff, these parameters are not affected and kept managed by the endpoints. Window Scaling Option is currently turned off, however, noted in section 5.1 (TCP Option Prerequisites) that synchronization of this option is possible via pre-establishing a pool of TCP sessions towards the surrogate servers with various WSCALE values. Congestion control and TCP performance tuning are out of the scope of this research paper.

Best regards,
Tomas Boros

Reviewer 3 Report

Looking at the results, the transparent evaluation produces bigger confidence intervals when the number of hops is increased, even after the redesign made. It would be worth commenting why that is happening and if bigger confidence intervals are expected with even more hops (even if 100 hops sounds as enough).

You say that to make the approach acceptable SDN controller needs to monitor network changes. To be honest I don't foresee any OpenFlow like SDN controller not monitoring the network since usually LLDP is generated within the controller. Even ryu does it that way. You may make clear if some kind of special monitoring is expected/needed.

This approach requires an upgrade in the dataplane that even actual whitebox switching may not be able to cope with after firmware upgrade.

You shall say how to avoid the TCP-Option removal.

Next time you shall upload the paper without editing marks. It looks like you didn't take the interest to put it in the proper form.

Finally (as the typical review topic), you didn't tackle secure connections.

Author Response

Dear reviewer,

Thank you for your review.

Confidence intervals are increasing due to the limited available resources of our testbed. An explanation was added at the end of section 5.2.

Network changes are indeed captured by the SDN controller, however, the recalculation of the installed paths was not implemented in the prototype. A sentence describing this approach was modified in section 5.2 to provide a clearer explanation.

In section 3.1 we further explained the datapath requirements. Using any legacy OpenFlow 1.3. compliant forwarder in the network is possible, only the forwarders, where a request router or a surrogate server is attached must be upgraded to our custom solution.

In section 5.1 we updated the description, which describes how it would be possible to eliminate the TCP option removal.

Changes in the document were tracked due to the requirement by the editors for faster detection of changes for the reviewers. (Reviewer n. 2 is currently in round 4 of reviews)

At the end of section 3.2, we devoted a paragraph explaining problems with secure HTTPs connections in detail and proposing alternative solutions on how to make the connections secure towards the clients.

Best regards,
Tomas Boros, Rastislav Bencel, Ivan Kotuliak

Round 2

Reviewer 2 Report

The authors are indicating this paper does not cover secure communication like https. Moreover, they said it is in the future/next research area. However, in general CDN environment, https session is normal communication type. Moreover, the proposed scheme does not cover/support the https-like secure communication type. 

Author Response

Dear reviewer,

thank you for your article review.

In the second round, we clearly state in the manuscript, that the solution does not support secured TSL based communication, thus breaking the HTTPs support. The article further mentions in section 3.2, that the solution is designed to work with HTTP 1.1 in unencrypted form.

Yellow highlighted sentences, that were not clear or hard to read, were re-phrased and several other typos and grammatical errors were fixed.

Best regards,
Tomas Boros, Rastislav Bencel, Ivan Kotuliak

Round 3

Reviewer 2 Report

During the review process in two round, this reviewer strongly suggests the inclusion of https support scheme, which is mandatorily required to check the objectiveness of the proposed scheme. As you knew, many applications in current CDN environment are utilizing https session. However, the proposed scheme does not support such https session,but the current proposed scheme is only targeting on http 1.1 environment. This reviewer does not understand why authors' statement is the right answer to two review comments. 

Author Response

Dear reviewer,

We understand the concerns with secured HTTPs connection, however, handing off such connection is impossible without modifications to the endpoints. Being able to hand off such a connection means there must be a serious vulnerability in the current TLS 1.3 standard, which would deprecate this protocol. Handing off TCP sessions might be useful in other use cases too, not just for CDN.

At the end of chapter 3.2, we devoted a paragraph explaining this problem in detail and proposing alternative solutions on how to make the connections secure towards the clients.

Best regards,
Tomas Boros, Rastislav Bencel, Ivan Kotuliak