Tags:
create new tag
, view all tags

Open Source Documents: Review - Opportunistic Wireless Broadcast

Info - Why am I doing this?

Acceptance Letter

Dear Mr. David Salyers:

Congratulations - your paper #1569128768 ('Opportunistic Wireless Broadcast (OWB): Dynamic Redundancy Detection in the Wireless Medium') for 8th IEEE International Workshop on Wireless Local Networks (WLN) has been
accepted, as a "8th IEEE International Workshop on Wireless Local Networks (WLN)" paper (if you have submitted your paper as a "regular paper", and now have been accepted as a "short paper", you will receive an additional e-mail with some more information).

WLN 2008 received XX submissions this year, of which XX were accepted as regular papers and XX as short (poster) papers. 

Camera ready copy of your paper is due 28 July 2008. Instructions on final
manuscript preparation will follow soon in another email (from the IEEE). EDAS will *not* be used for the upload of the final paper.

The reviews are below or can be found at http://edas.info/showPaper.php?m=1569128768:

Please note the following:
- For authors, the registration amounts are USD 495 for IEEE members (must provide IEEE membership number) and USD 625 for non-members. Authors need to register by July 28, 2008. A registration is good for up to three accepted papers.
- If you need a Visa to travel to Ireland in order to present your paper, please apply for the Visa immediately as getting granted a Visa takes some time (more information on this can be found at http://www.ieeelcn.org/ - "Travel Information" - "Visa").

We look forward to seeing you in Montreal in October!

Kind regards,
Farid Naït-Abdesselam and Walaa Hamouda, WLN 2008 TPC Chairs

Commentary

Actual acceptance rate was 9 out of 22 papers per the introduction by the workshop chairs

Review 1 - Accept

======= TPC Review 1 =======

*** Scientific/Technical Quality: How would you rate the scientific/technical quality of the paper? (1 being worst score, 5 being best score)
Average (3)

*** Innovation: How would you rate the innovation of the paper, the news being received by the reader? (1 being worst score, 5 being best score)
Average (3)

*** Presentation Quality: How would you rate the quality of presentation within the paper? (1 being worst score, 5 being best score)
Excellent (4)

*** Overall Recommendation: What is your over all recommendation for
this paper?
Accept (10-20%) (4)

*** Contributions: Do the presented results constitute a significant advance (e.g., technical depth, novelty, creative solution, etc.)? Yes or No.  Please explain in one to three sentences.

The paper presents an opportunistic broadcasting scheme for wireless LANs. The idea is simple and innovative. I like the fact that the authors present results from real experiments.

*** Strengths: What are the most important merits of the paper?  Please explain in one or more sentences.

Nice idea, good presentation, results from real experiments (which is not often the case with several papers).

*** Weaknesses: What are the major weaknesses in the paper? Please explain in one or more sentences.

From my understanding in 802.11 broadcast always takes place at the lowest transmission rate (1 Mbps in 11b I think). Given this would it always be better to resort to broadcasting or would it be more efficient to resort to unicasting at the highest rate (say 11Mbps for 11b) ? I believe the authors have not addressed this issue. 

Secondly, it is not clear if several of the results are from a single run ? It would be better to present results from multiple runs and include the average and confidence intervals.

*** Feedback to Authors: Please provide detailed comments that will help the authors to understand the weaknesses in their paper and improve their work.  This section is very important if you rate the paper as a reject.

Overall nice idea. Would only work for last-hop WLAN links only though.

*** Do you consider this an award quality paper?: Is this an award quality paper?  Yes or No.

No.

Commentary - Striegel

Reviewer Comment From my understanding in 802.11 broadcast always takes place at the lowest transmission rate (1 Mbps in 11b I think). Given this would it always be better to resort to broadcasting or would it be more efficient to resort to unicasting at the highest rate (say 11Mbps for 11b) ? I believe the authors have not addressed this issue.
Response For compatibility, devices would default to the lowest transmission rate so as to cover all devices. However, as we are only interested in devices supporting OWB, it is not necessary to broadcast at the lowest rate. In the heterogeneous case where some devices support slow speed (1 Mb/s) and others fast (11 Mb/s), one could broadcast at the slower and benefit as the slower device had to be broadcast to in the first place. If both devices support fast broadcast receipt (receipt is almost always not an issue), then the faster speed would be preferred.

Reviewer Comment Secondly, it is not clear if several of the results are from a single run ? It would be better to present results from multiple runs and include the average and confidence intervals.
Response The results come from multiple runs. Full details are available in Dave's thesis which can be found here.

Review 2 - Reject

======= TPC Review 2 =======

*** Scientific/Technical Quality: How would you rate the scientific/technical quality of the paper? (1 being worst score, 5 being best score)
Average (3)

*** Innovation: How would you rate the innovation of the paper, the news being received by the reader? (1 being worst score, 5 being best score)
Marginal (2)

*** Presentation Quality: How would you rate the quality of presentation within the paper? (1 being worst score, 5 being best score)
Bad (1)

*** Overall Recommendation: What is your over all recommendation for
this paper?
Reject (30-50%) (2)

*** Contributions: Do the presented results constitute a significant advance (e.g., technical depth, novelty, creative solution, etc.)? Yes or No.  Please explain in one to three sentences.

The author has proposed a a scheme called opportunistic wireless broadcast (OWB) that opportunistically aggregates redundant content over short timescales into inified broadcasts in order to dratically improve the efficiency of streaming media.

*** Strengths: What are the most important merits of the paper?  Please explain in one or more sentences.

Proposed an interesting idea and conducted experiments

*** Weaknesses: What are the major weaknesses in the paper? Please explain in one or more sentences.

The mechanism and motiviation of the OWB proposed are not clearly illustrated. There are several open questions regarding the scheme which will be discussed below.

*** Feedback to Authors: Please provide detailed comments that will help the authors to understand the weaknesses in their paper and improve their work.  This section is very important if you rate the paper as a reject.

The author has proposed a a scheme called opportunistic wireless broadcast (OWB) that opportunistically aggregates redundant content over short timescales into inified broadcasts in order to dratically improve the efficiency of streaming media. Some experiments have been conducted. Although the idea seems to be interesting, there are several issues for this paper.

First, the mechanism and motivition of the proposed OWB are not clear. I assume that the context is about multiple clients receiving the same live streaming data. Otherwise, it is unlikely to aggregate the redudant data in a real time environment. For instance, in video on demand situation, different clients tend to have different starting time. 

Second, from Fig. 1 of your paper, it seems that you try to reduce sending repeated unicast packets. It is not clear how much overhead will be produced by MD5 checksum generation and verification on every packet. Does it affect the real time streaming rate ?

*** Do you consider this an award quality paper?: Is this an award quality paper?  Yes or No.

No

Comments - Striegel

Reviewer Comment First, the mechanism and motivition of the proposed OWB are not clear. I assume that the context is about multiple clients receiving the same live streaming data. Otherwise, it is unlikely to aggregate the redudant data in a real time environment. For instance, in video on demand situation, different clients tend to have different starting time.
Response The reviewer is correct in that the clients must be receiving the same data in order to have it aggregated. We note that no additional penalty occurs for having OWB running and thus is only beneficial when applicable. Moreover, we note that per our observations in the paper regarding the amount of data as well as the dissertation by the now Dr. Salyers that there is considerable redundancy / opportunities present, especially at peak bandwidths, i.e. the most redundancy occurs when the link is congested.

Reviewer Comment Second, from Fig. 1 of your paper, it seems that you try to reduce sending repeated unicast packets. It is not clear how much overhead will be produced by MD5 checksum generation and verification on every packet. Does it affect the real time streaming rate ?
Response As noted in the paper, a COTS notebook which served as the OWB aggregation point is fully capable of well over 100 Mb/s of computing MD5 checksums and comparisons for aggregation. Unlike the Rabin fingerprint algorithm which can incur a dynamic overhead in terms of searching, the MD5 checksum is computed over the payload resulting in a fixed cost per packet, much akin to the Ethernet checksum in the packet. It does not have an impact on real-time streaming but rather the entire OWB process can significantly improve the bandwidth available to the channel due to reduced contention.

Final Comments - Striegel

This paper has a fairly long history of near misses. As I have time, I'll dig up the historical reviews and also post them for reference.

Topic revision: r1 - 08 Jan 2009 - AaronStriegel
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2013 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback