1 / 12

Do we need PCP?

Do we need PCP?. Hongyu Gao Yinzhi Cao. Outline. Design Goal Underlying Assumption Design Detail Evaluation Deployment Conclusion. Design Goal. Do we need fairness? PCP claims in the design goal: YES! However, it later claims: Fairness is less important than transfer time

taro
Télécharger la présentation

Do we need PCP?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Do we need PCP? HongyuGao Yinzhi Cao

  2. Outline • Design Goal • Underlying Assumption • Design Detail • Evaluation • Deployment • Conclusion

  3. Design Goal • Do we need fairness? • PCP claims in the design goal: • YES! • However, it later claims: • Fairness is less important than transfer time • We do NOT agree! Fairness is important.

  4. Underlying Assumption • Packet can reach the receiver at the first time it is sent through out the whole paper • Unrealistic! • Network level protocol does NOT provide reliable service. Instead, it provides best-effort service. • Noisy channel, random error may cause packat lost

  5. Consequences • Probe is not accurate • Rate compensation is delayed We want to see how packat lost have effect on PCP.

  6. Design Detail • We assume n users probe at the same time. • Some of them may succeed at the same time. • They assume bandwidth falsely. • They all send packets at the assumed high rate. • Packat Lost / Oscillation

  7. Evaluation • Missing crucial information • How well does the congestion control algorithm work when there is congestion in the network? • Will the performance degrade gracefully? • In the evaluation, there is NO congestion in the network

  8. Evaluation • Let us look at the first graph of Figure 10. • They transmit 1000 package in 400ms. • Let’s do a simple math. Package size = 1500bytes(in common Ethernet) 1500bytes*8b/bytes*1000/0.4s = 28.6Mb/s But they set interarrival times to be 60% of system load. So 40Mb/s*0.6=24Mb/s How can they achieve a transmission rates larger than possible?

  9. Deployment • What do we gain if we switch to PCP? • Slow Start to Quick Start (But if transmission is small, do we care about time? If transmission is large, slow start is only a very small portion.) • Good Performance when links are mostly idle.

  10. Deployment • What do we lose if we use PCP? • Possible Starvation when TCP exists(If no modification to original PCP.) And no evidence show us that PCP has better performance if TCP exists(maybe worse). • No communications with TCP client (They claim they can, but not implemented. And they don’t know if there is problem.)

  11. Conclusion • Design Goal - Unreasonable • Underlying Assumption - Unrealistic • Design Detail - Flawed • Evaluation - Incomplete • Deployment - Unlikely

  12. We ask you a question. Do you use PCP?

More Related