<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 8 Aug 2019, at 15:43, Klaus Schneider wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Dear Dave,<br>
<br>
Thanks for the draft. I want to ask a related question.<br>
<br>
As far as I understand, the Hop-by-Hop flow balance congestion control makes the following two assumptions:<br>
<br>
1. The capacity of each link is fixed and you know its value (e.g. 10 Gbps)</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Current schemes mostly do, but it isn’t an inherent characteristic. Schemes like the hop-by-hop interest shaper can adjust in one or two link RTTs. One thing to be careful of is deep transmit buffering if you can only do shaping on enqueue, because the link will stay saturated for a long time if you can’t adjust quickly. </p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">2. You can access the current queue size/occupancy of each outgoing link (to check if it is congested)<br>
</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Even better is to have a lower layer that can report to you what’s going on rather than having to infer bandwidth changes from queue depth getting bigger. A complicating factor of course is tunnels, where you have little to no idea what’s going on inside. That’s what you’re addressing below.</p>
<p dir="auto">I’ll also point out the (hopefully obvious) observation that while knowing data size isn’t a panacea, it’s hard to see how it could to <em>worse</em> than interest counting.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">I think these assumptions are fine for most networks, but I want to ask about a special case where they don't hold.<br>
<br>
<br>
Specifically, consider a global ICN testbed deployment where NDN routers are connected via IP tunnels that span an unknown number of IP routers.<br>
<br>
Here, you don't know the effective tunnel capacity (since there is an unknown amount of IP traffic). You can access the local router queue occupancy, but it's not very useful (since congestion can happen between two of the IP routers inside the tunnel).<br>
</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Correct. Datagram tunnels suck. Maybe the LOOPS work in IETF might make some progress here, but I’m not optimistic. (see <a href="https://datatracker.ietf.org/wg/loops/about/" style="color:#3983C4">https://datatracker.ietf.org/wg/loops/about/</a>)</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Assume you have full control over the NDN routers, but no control over the IP routers. You can choose TCP or UDP tunnels.<br>
<br>
How would you design the congestion control?<br>
<br>
<br>
There are some existing designs for this case (e.g. <a href="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf" style="color:#777">http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf</a> <a href="https://datatracker.ietf.org/meeting/interim-2017-icnrg-03/materials/slides-interim-2017-icnrg-03-sessa-icn-congestion-control-how-handle-unknown-and-varying-link-capacity-ahlgren/" style="color:#777">https://datatracker.ietf.org/meeting/interim-2017-icnrg-03/materials/slides-interim-2017-icnrg-03-sessa-icn-congestion-control-how-handle-unknown-and-varying-link-capacity-ahlgren/</a>). But none of them have been tested much in practice.<br>
</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I’m familiar with both of these. I’ve only given bit of thought to how to prevent congestion of data packets coming back, since their loss incurs a big performance hit. (It’s one reason why the pure AQM approach in the ICN paper you did for 2016 isn’t that appealing to me - but that’s a longer discussion).</p>
<p dir="auto">I suspect there is only so much you can do without changing the protocols. CCNx has hop-by-hop congestion NACKs, but as I recall NDN doesn’t, and Van recently gave a talk in which he argued that they are a certified “bad idea” or something equivalent. I disagree, but have not had much success in the past influencing the NDN design.</p>
<p dir="auto">Another thing not done even in CCNx implementations is to ALWAYS reserve enough bandwidth on the inverse link to carry a congestion NACK back if you have to drop a Data packet due to congestion. That way recovery can be a lot quicker than waiting for a timeout, and if you support in-network retransmission, it can occur at the RTT between the bottleneck and the producer/cache rather than end-to-end.</p>
<p dir="auto">A third thing one could do is piggyback queue state on returning Data or NACK packets. This helps deal with the general case of varying bandwidth, even when the path goes asymmetric and there aren’t convenience Interests to piggyback it on going in the opposite direction. Hysteresis is of course the big enemy here.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Best regards,<br>
Klaus<br>
</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Thanks for the feedback!</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">On 8/3/19 7:14 AM, David R. Oran wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">NDN folks,<br>
<br>
Those of you interested in congestion control for NDN might care to take a look at the draft I submitted to ICNRG about doing a better job of resource allocation than current interest-counting schemes. You can find it at:<br>
<br>
<a href="https://datatracker.ietf.org/doc/draft-oran-icnrg-flowbalance/" style="color:#999">https://datatracker.ietf.org/doc/draft-oran-icnrg-flowbalance/</a>.<br>
<br>
This is something I’ve been noodling on for a long time because of my continuing interest in congestion control for ICN. It derives from some work I did at Cisco a few years ago which I believe has become timely. A number of interesting ICN use cases have either highly variable (e.g. video), very large (e.g. scientific data), or very small (e.g. IoT sensor) data objects, while all the congestion control schemes currently published (to my knowledge) only do interest counting which can’t account for this variability.<br>
<br>
I’m obviously super-interested in what people think of this approach. It is deceptively simple (only requires one new TLV with easy switch from interest counting to fine-grained byte-based resource control for congestion and possibly QoS extensions). However, like most things with NDN or CCNx, it has interesting subtleties with respect to interest aggregation and consumers trying to game the system, both of which are covered in the spec.<br>
<br>
I’d appreciate it if you’d post your comments on the ICNRG list <icnrg@irtf.org> in order to have one place to discuss it. However, if you’d prefer to reply to non-interest or to me privately, that’s ok as long as you don’t mind if I repost responses and further discussion in ICNRG.<br>
<br>
As a final note, this has Cisco IPR on it. I’ve talked to the Cisco folks and they’ll put in the usual Cisco IETF-oriented IPR declaration when they get back from vacation (i.e. don’t hold your breath).<br>
<br>
Thanks much!<br>
<br>
DaveO<br>
_______________________________________________<br>
Ndn-interest mailing list<br>
Ndn-interest@lists.cs.ucla.edu<br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" style="color:#999">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a></p>
</blockquote><p dir="auto">_______________________________________________<br>
icnrg mailing list<br>
icnrg@irtf.org<br>
<a href="https://www.irtf.org/mailman/listinfo/icnrg" style="color:#777">https://www.irtf.org/mailman/listinfo/icnrg</a></p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">DaveO</p>
</div>
</div>
</body>
</html>