Comments for Nalanda

Comment on Internet Measurement by Randy Katz

Randy Katz — Tue, 18 Nov 2008 18:18:16 +0000

our goal was to get x-trace into high leverage software packages, like Hadoop. It does turn out to be difficult to instrument apps if they don’t have their network interface code all in one nice place.

Comment on Middleboxes and Indirection by Randy Katz

Randy Katz — Sun, 09 Nov 2008 21:16:48 +0000

The trigger mechanism in i3 certainly appears to be very powerful and general. It makes it possible to implement several functionalities at once, which is a good thing. The main problem, in my view, is some of the performance issues, such as the hop-by-hop latency (stretch) can be a problem, at least in the wide-area. We’ll see this again when we look at datacenters, where some of the performance and security issues can be sidestepped.

Comment on XORs in the Air: Practical Wireless Network Coding by Randy Katz

Randy Katz — Thu, 09 Oct 2008 20:44:56 +0000

Did you have any reaction to the implied implementation complexity? Managing the packet pool to achieve good coding gain seems complicated to me. As far as I know, people have not chosen to take this approach in practical multi-hop deployments. Nevertheless, an interesting paper at the intersection between theory and practice.

Comment on ExOR: Opportunistic Multi-Hop Routing for Wireless Networks by Ashwin

Ashwin — Thu, 09 Oct 2008 01:34:06 +0000

I’ll concede that overall spectrum utilization is good; but my question is related to throughput from multiple sources. The restriction to one source sending at a time, and strict ordering of sources, seems to imply that sources will be constrained by other sources, leading to poor network utilization, and probably the TCP backoff issues that we’ve already discussed.

Comment on ExOR: Opportunistic Multi-Hop Routing for Wireless Networks by Matthias Goerner

Matthias Goerner — Thu, 09 Oct 2008 01:28:07 +0000

“The requirement for ordering of transmissions amongst all forwarders surprised me;” I guess that for really large networks where there is absolutely no way of the node on the outer edge overhearing a node in the middle, this will probably be relaxed for efficiency.
But let’s assume this is not the case, let’s assume a graph like A-B-C-D, B can send to A and C to D without collision (because signal difference is at least 10dB). This is what you were expecting that several stations send at the same time.
But notice that B can also send to D directly, but only if C is not sending. That means that B can send a packet to D directly and we save a hop, but it requires that C is silent during that time.
In short, if only one node is sending at a time, the signal is propagating further without being dominated by other signals and needs less hops. And since less hops means less number of total transmissions, the overall usage of the spectrum is pretty good.

Comment on A High-Throughput Path Metric for Multi-Hop Wireless Routing by Ashima Atul

Ashima Atul — Tue, 07 Oct 2008 19:39:16 +0000

I agree about your point regarding the probe packets. The probe packets sent are of fixed size at an average rate of T and do not depict the same loss rate that the data packets may face.

Comment on Scaling Internet Routers Using Optics by Randy Katz

Randy Katz — Tue, 23 Sep 2008 20:23:16 +0000

You have an excellent summary of the high points above. I will try to put the paper into some context today.

Comment on Fundamental Design Issues for the Future Internet by Nalanda » Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism

Thu, 18 Sep 2008 17:52:37 +0000

[...] was odd reading this paper alongside Shenker’s. Although it is from three years earlier, it seems much more modern, almost prescient in its [...]

Comment on Random Early Detection Gateways for Congestion Avoidance by Randy Katz

Randy Katz — Wed, 17 Sep 2008 03:53:26 +0000

Given RED’s desire to handle bursty traffic well, it is tricky to do that and achieve fairness at the same time. It is kind of like FQ with a long history window. Note that FQ can be chosen as the router’s scheduling algorithm even if random drop is the dropping strategy, and this is how it is usually implemented.

Comment on Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks by Nalanda » Random Early Detection Gateways for Congestion Avoidance

Nalanda » Random Early Detection Gateways for Congestion Avoidance — Mon, 15 Sep 2008 16:58:56 +0000

[...] are similar to those available in TCP (drop a packet) and explicit notification as proposed by Chiu and Jain (1989), RED detects congestion differently. Instead of reporting congestion when it occurs (i.e., queues [...]