NDN addresses a different issue. It's more like a design for a content-delivery network. How would that help with upward bottlenecks on asymmetrical home connections?
Perhaps the right question to ask is "What is do you really need to know from the next node upstream?" Suppose you could query an upstream router for congestion info, and get back:
- In the last N0 seconds, this node received N1 packets from your IP address, dropped N1 for congestion reasons, dropped N2 for other reasons, and forwarded N3.
- Total bytes from you, N4. Total bytes forwarded, N5.
- Maximum link capacity bytes/sec, N6. Your upload limit is N7 bytes/sec.
- For forwarded packets, min/max/avg delay time N8.
- If QoS is supported (DCSP field meaningful), this info is repeated for each QoS level that does anything.
That's basically the information you need to tune a "bufferbloat" algorithm and evaluate how well it is working. The latter is important. In the real world, everybody is guessing about this. If you know, you can tune.
Some simple mechanism for that, perhaps a new ICMP message type, would be useful.
As long as the query packet contains a nonce, so you can match queries with replies, there's no real security issue. Anything which sees that packet sees the traffic anyway. One packet in, one packet out has no DDOS amplification potential. If a router doesn't understand the query, there's no reply, and the bufferbloat controller has to guess.
NDN has a request/reply model with symmetric forwarding.
This means that an upstream network provides feedback to the downstream one. NDN has nothing to do with content delivery.
