How many Youtube subject tags will fit in *your* routers' TCAM?
http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
[ Can someone convince me this isn't the biggest troll in the history
of the internet? Cause it sounds like shoehorning DNS /and Google/ into
IP in place of, y'know, IP addresses. ]
Cheers,
-- jra
I didn't read it that way exactly, especially in light of this not in
the Wikipedia article:
"Application-layer designs have also been proposed for deploying a
content-centric interface. This has benefits such as easier
deployment, backwards compatibility and more flexible delivery support."
https://en.wikipedia.org/wiki/Named_data_networking
It's an interesting concept, but it ain't gonna replace TCP/IP, DNS,
or IP addresses anytime soon. 
- - ferg
- --
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
"Interface" sure.
But the dangers of replacing actual /addresses/ with things which are not is sufficiently well understood that even Van Jacobson ought to know about 'em, right?
"Interface" sure.
But the dangers of replacing actual /addresses/ with things which
are not is sufficiently well understood that even Van Jacobson
ought to know about 'em, right?
Compare & contrast: There is still large-scale resistance (for lack of
a better term) to IPv6 deployment, so what chance does deployment of
Named Data-Networking stand?
- - ferg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256"Interface" sure.
But the dangers of replacing actual /addresses/ with things which
are not is sufficiently well understood that even Van Jacobson
ought to know about 'em, right?Compare & contrast: There is still large-scale resistance (for lack of
a better term) to IPv6 deployment, so what chance does deployment of
Named Data-Networking stand?- - ferg
This idea needs more simmer time.
https://en.wikipedia.org/wiki/Named_data_networking
" Juno also introduces the concept of a delivery-centric interface, which extends the traditional content-centric interface to allow applications to stipulate multiple diverse delivery requirements that place certain constraints on how the content should be provided. For instance, these constraints can deal with such things as performance, resilience, security, monetary cost and anonymity."
Almost sounds like the perfect protocol to allow the combination Internet/content provider to keep all content coming from where they want the content to come from instead of the freedom to choose where the content comes from.
--John Schiel
How many Youtube subject tags will fit in *your* routers' TCAM?
http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch
-consortium-to-replace-tcpip[ Can someone convince me this isn't the biggest troll in the history
of the internet? Cause it sounds like shoehorning DNS /and Google/
into IP in place of, y'know, IP addresses. ]I didn't read it that way exactly, especially in light of this not in the Wikipedia article:
"Application-layer designs have also been proposed for deploying a content-centric interface. This has benefits such as easier deployment, backwards compatibility >and more flexible delivery support."
https://en.wikipedia.org/wiki/Named_data_networking
It's an interesting concept, but it ain't gonna replace TCP/IP, DNS, or IP addresses anytime soon.
- - ferg
Given how long the process has been to go from IPv4 to IPv6, I would imagine something like this taking much longer to take root and spread out to the masses. It is a curious concept though and the papers written on the consortium site may be work a quick read.
-gary
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _
Please make note of our new e-mail domain name: TEAMHGS.COM.
Request you to update your address book accordingly.
Confidentiality Notice:
The information contained in this electronic message and any attachments to this message are
intended for the exclusive use of the addressee(s) and may contain confidential or privileged
information. If you are not the intended recipient, please notify the sender at
Hinduja Global Solutions or postmaster@teamhgs.com immediately and destroy all copies of
this message and any attachments.
9284f6a0-bf16-11e3-b1b6-0800200c9a66
I don't think IPv4 to IPv6 is taking long because it's technically difficult,
it is taking long time because it's hard to justify it commercially, no one is
paying you premium to get it, because it does not provide anything your
customers want.
We could probably deploy completely new protocol stack in 5 years, if there
was business incentive, if customers would switch to you from current
provider, if you are providing this.
Having said that I skimmed through NDN and it seems like
yet-another-flow-forwarding-concept. I quickly lose interest when I run into
proposal where state does not end after reading header. Having all these
states sitting in FIB does not seem anywhere near plausible even with moore's
law hand waving.
I'm sure better than IP is possible, but I can't tell what it is. I think IP
addresses are more relevant today than they should be. We already do rely on
doing 2 lookups, IP (infrastructure) and DNS (dictionary/service), and IP
addresses probably can be made completely uninteresting low-level detail by
looking how to revamp host's dictionary lookup, adding complexity there has
very little impact on scaling.
Not me. The description of the thing wanders inscrutably from a sort
of generalized distributed content caching (which is a great idea
readily buildable without any change in paradigm whatsoever) to stuff
that is vaguely reminiscent of the John Day BS which despite all
reason manages to suck in yet another networking researcher from time
to time.
Regards,
Bill Herrin
Interesting, here are my speaking notes from a talk I gave at
Hackerspace/SG in June 2011. Slightly different but in a similar
spirit depending on your sense of "similar":
THE END OF DNS
A Quick History
The internet uses host names but routing is done based on
numeric IP addresses usually.
For example world.std.com is 192.74.137.5 in dotted notation or
0xC04A8905 hex or 1100000001001010100010010000000101 binary or
3,226,110,213.
world.std.com can be looked at as:
w o r l d . s t d . c o m
073557 071154 062056 071564 062056 061557 066400
So, we need to go from the host name to the ip address and back
reliably.
Originally we used a hosttable which was simply a text file, on
unix-like systems you see a remnant of it with entries like
127.0.0.1 localhost
192.74.137.5 world.std.com world
with other information spread across /etc/nets and /etc/gateways, a
snippet of the distributed format from RFC810 is:
NET : 18.0.0.0 : LCSNET :
GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW :
HOST : 10.0.0.73 : SRI-NIC,NIC : FOONLY-F3 : TENEX :
NCP/TELNET,NCP/FTP, TCP/TELNET, TCP/FTP :
HOST: 10.2.0.11 : SU-TIP,FELT-TIP :::
This was downloaded from a single host, often at midnight, and there
was a unix program (hosttable) to reformat the information for Unix.
Yes, every host on the internet downloaded a common file, often every
night.
This wouldn't scale well so Paul Mockapetris devised "DNS" or Domain
Naming Service.
The idea is very simple, each site would be responsible for their own
domain and to respond to simple remote requests for name to ip address
mappings or back again.
There would be a root, or multiple roots, which would respond to
requests to locate who should be asked about a domain, for example if
you want to know the ip address for world.std.com the conversation
goes roughly:
(To Root Server): Where is the COM server?
(From Root Server): SOMEHOST
(TO SOMEHOST): Where is the STD.COM server?
(From SOMEHOST): 192.137.74.112
(TO 192.74.137.112): WHAT IS WORLD.STD.COM's IP ADDRESS (A RECORD)?
(FROM 192.74.137.112): 192.74.137.5
It's amazing. to me, that it works let alone so quickly!
But let's examine this, WHY do this mapping?
1. Computationally / Memory efficient
2. Sometimes IP changes, host name can be more stable. One reason to
change IP is change of ISP, or LAN re-organization.
3. DNS Tricks! load balancing (e.g., round-robin), failover,
content caching and distribution.
4. Multiple interfaces
5. Aliases
We also overload some other functions on DNS such as who is this
host's mail server or their SPF information. But let's stick to host
to ip address mapping.
THE BIG IDEA:
Why not just use the host names as ip addresses? They're integers.
In IPv6 they're rather long integers, 16 bytes.
Looking thru hundreds of millions of web server log records I found
host names to be about 32 bytes long, including dots.
So sending the host name as the ip address is not an enormous
expansion over current plans for IPv6, about double on average though
variable length must be accomdated for long host names, up to 1K or
thereabouts.
Routing by ip addresses is really very simple:
A router looks at some number of bits of an IP address, the "network"
portion, and either knows where to hand this packet next, either
another router or the actual host and we're done, or only knows that
any network which isn't in its table needs to be handed to a "default"
router neighbor and with luck the packet will eventually find a router
which knows what to do with the packet.
There might use varying number of bits to determine the best router to
send a packet to next.
At the "center" there are these routers which have NO default, they
either know how to get your packet on its way or it has no route and
is discarded.
Really very simple, all the complexity is in keeping the information
in each router current. This turns out to be not only an information
distribution problem but also an information distribution STABILITY
problem.
But it's not our problem today.
All we need concern ourself with is that there is a host name to ip
addr mapping and these ip addresses are used in routing packets,
that's the point.
But why not just use the host name and skip the mapping?
FQDNs are hierarchical, we can pick them apart and start routing a
packet looking to go to world.std.com by routing to (or towards) a COM
router, then a STD.COM router, and finally hand it off to
WORLD.STD.COM.
No doubt the devil is in the details, but tonight we're interested in
whether it's worthwhile working out those details. Are there fatal
flaws?
One complaint might be computational complexity. Integers are easy to
put into tables and use as indexes. Most real routers even have
specially built memory to speed this up.
Then again the 70s are over, the 80s are over, the 90s are over, the
2000s are over, computers are fast and getting faster and parallelism
(such as multiple cores and threads) is commodity as are relatively
large memories.
If the average host name is about 32 characters and there are about a
billion hosts then it takes around 32GB to hold all that information,
maybe twice that with table overhead, 64GB. I can buy 64GB flash
drives for around $100! They're too slow but I hope you get my point.
And, besides, you only need to hold each network portion once in a router's
memory, not for every host:
COM
THEWORLD 192.74.137.0
SHELL01 71
DNS 112
that's simple.
To search the table the router could use a perfect hash function or as
close to that as we really need.
It would probably be better if we all agreed on one or a few hash
functions but it's not necessary, it's only used inside a router, but
it might make debugging easier.
Bazinga! No DNS!
But what about our list of uses of host to ip mappings?
1. Computationally / Memory efficient
Who cares?
2. IP changes?
Build it into ICMP and BGP infrastructure, that's a routing
problem.
We already have another system, ARP, which deals with similar
problems to map IP to MAC addresses.
3. DNS Tricks!
Trix are for kids. But, again, a routing problem.
4. Multiple interfaces
Same sort of problem, mostly a last hop problem.
5. Aliases
Still a last hop problem
What are the problems?
What do we gain?
We get rid of this huge, noisy, complex infrastructure.
We still need registries and registrars because we still need to file
who "owns" a host name.
But we can get rid of the entire RIR structure, the five regional
organizations which hand out IP block, usually for $1000 or more per
year depending on the number of bits in the network part (less is more
expensive.)
Well, they could still coordinate some routing functions, ASNs, etc.
No DNS, no DNS attacks!
To me this seems more secure tho that's a dangerous conjecture to make.
But we have removed a rather public, distributed target and put most
of the function in the routing infrastructure directly which tends to
be more secure. For example, you don't accept routing updates from
anyone, only trusted hosts. And in the near future we can expect even
that to be "signed".
Speaking of signed, no DNNSSEC! DNSSEC is a fairly simple concept,
sign DNS information exchanges using public key cryptography, with a
rather complex operational overhead such as key updates and
revocations. Gone!
I've discussed this on very technical (private) mailing lists with the
sort of people who built the MSN infrastructure, Morgan-Stanley (no
more than 100msecs downtime PER YEAR!), Google, Vonage, etc.
Worst complaint: We're so accustomed to thinking in terms of DNS that
there must be SOMETHING wrong with your idea!!
A few thought it was great and made reference to other discussions
over the years which were somewhat similar tho not quite as sweeping.
SO WHAT IS WRONG?
Here¹s my $0.02. I¹m only going to touch on a small part of what I
understand NDN to be‹ namely making caching a first class citizen of the
network. When you think about the types of traffic currently carried over
our collective networks, there might be value if the network eco system
more natively supported caching.
Van¹s first paper proposing this NDN concept (afaik) was in 2009.
If we were to get into the ³way-back² machine to say 2003, when
peer-2-peer was a big app, one might have then decided that we really need
to make ³peer-2-peer² a first class citizen of the network. In fact the
IETF tried [at some level] to do this with the DECADE WG. The app space
evolved, p2p is no longer as prevalent, and DECADE saw/got little
traction.
In 1998, we might have been thinking about making NNTP a first class
citizen of the network.
Maybe we need to think about making *software* [instead of a specific
service] a first class citizen of the network. What do I mean by this?
If software were a first class citizen of our networks in 2003, we might
have hopped onto our routers and done a ³yum install decade²‹ which would
install software that would make the network eco system more efficient at
supporting p2p traffic.
Today, on our network eco system we might do a ³yum uninstall decade² and
then do a ³yum install caching²‹ which might embed caching functionality
into our routing eco system‹ hopefully making the delivery of cacheable
content more efficient.
In N years, when there is yet another new app pushing the network eco
system, we might then be doing a ³yum uninstall caching² and instead doing
a ³yum install new-app² which would make the network eco system more
efficient at supporting this new-app.
Brian
Hi,
How many Youtube subject tags will fit in *your* routers' TCAM?
http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
[ Can someone convince me this isn't the biggest troll in the history
of the internet? Cause it sounds like shoehorning DNS /and Google/ into
IP in place of, y'know, IP addresses. ]
Well, you don't need addresses for clients, just for content... From the architecture page at http://named-data.net/project/archoverview/:
"Note that neither Interest nor Data packets carry any host or interface addresses (such as IP addresses); Interest packets are routed towards data producers based on the names carried in the Interest packets, and Data packets are returned based on the state information set up by the Interests at each router hop."
So it's basically suggesting a NAT-like table in every single router. And we all know how well NAT boxes scale...
Cheers,
Sander
Well, as I suggested, I didn't think it was nearly that easy to do.
It sounds to me like they want to put *Google* in every router.
Cause no one who posits this stuff has, apparently, ever had to do network
diagnosis.
You put too much distributed state in the network and it comes apart. We're
nearly there now with IPv4.
Cheers,
-- jra
As far as I understand, NDN's basic premise is to install "names" into the network layer. I don't think they (the NDN inventors) consider it as a new "app" at this point, even tough eventually it may merely stay as a new app.
I think the final thing that will determine the success of NDN is whether or not pushing names into the network layer rather than handling it at the app layer is going to return significant enough benefits. On the positive side, we will get rid of name -> address -> name mapping we are doing with DNS, we will enjoy content caching in routers themselves without relying on content servers to do it for us, and the story of upgrading to IPv6 will be over. On the negative side, we will have to deal with a whole new set of security and privacy issues (I can see a new wave of funding for cyber-security folks), we will need to revamp our routers (arguably which seems to attract Cisco so far) to handle names rather than IP addresses, and most importantly re-educate our practitioners to configure these "revamped" routers!
The key question is that do we really need to push the names into the network layer? I personally don't see this will happen, particularly as a replacement to TCP/IP as was laid down in the slashdot article. The best bet, IMHO, for NDN is to establish software-based NDN routers that maintain content tagged with names. One way to imagine I guess is to consider each router as a NAT box for this. I just can't see it replacing IP-based forwarding. We all wish things were so easy to change, but simply they are not.
Best,
-Murat
The principle questions still stand unanswered:
What is the motivation for this? What do you gain? Does it create some
large architectural and performance in efficiency?
- - ferg
As far as I understand, NDN's basic premise is to install "names"
into the network layer. I don't think they (the NDN inventors)
consider it as a new "app" at this point, even tough eventually it
may merely stay as a new app.I think the final thing that will determine the success of NDN is
whether or not pushing names into the network layer rather than
handling it at the app layer is going to return significant enough
benefits. On the positive side, we will get rid of name -> address
-> name mapping we are doing with DNS, we will enjoy content
caching in routers themselves without relying on content servers to
do it for us, and the story of upgrading to IPv6 will be over.
On the negative side, we will have to deal with a whole new set of
security and privacy issues (I can see a new wave of funding for
cyber-security folks), we will need to revamp our routers (arguably
which seems to attract Cisco so far) to handle names rather than IP
addresses, and most importantly re-educate our practitioners to
configure these "revamped" routers!The key question is that do we really need to push the names into
the network layer? I personally don't see this will happen,
particularly as a replacement to TCP/IP as was laid down in the
slashdot article. The best bet, IMHO, for NDN is to establish
software-based NDN routers that maintain content tagged with names.
One way to imagine I guess is to consider each router as a NAT box
for this. I just can't see it replacing IP-based forwarding. We all
wish things were so easy to change, but simply they are not.Best,
-Murat
Here�s my $0.02. I�m only going to touch on a small part of
what I understand NDN to be� namely making caching a first class
citizen of the network. When you think about the types of
traffic currently carried over our collective networks, there
might be value if the network eco system more natively supported
caching.Van�s first paper proposing this NDN concept (afaik) was in
2009.If we were to get into the �way-back� machine to say 2003, when
peer-2-peer was a big app, one might have then decided that we
really need to make �peer-2-peer� a first class citizen of the
network. In fact the IETF tried [at some level] to do this with
the DECADE WG. The app space evolved, p2p is no longer as
prevalent, and DECADE saw/got little traction.In 1998, we might have been thinking about making NNTP a first
class citizen of the network.Maybe we need to think about making *software* [instead of a
specific service] a first class citizen of the network. What do
I mean by this?If software were a first class citizen of our networks in 2003,
we might have hopped onto our routers and done a �yum install
decade�� which would install software that would make the network
eco system more efficient at supporting p2p traffic.Today, on our network eco system we might do a �yum uninstall
decade� and then do a �yum install caching�� which might embed
caching functionality into our routing eco system� hopefully
making the delivery of cacheable content more efficient.In N years, when there is yet another new app pushing the network
eco system, we might then be doing a �yum uninstall caching� and
instead doing a �yum install new-app� which would make the
network eco system more efficient at supporting this new-app.Brian
How many Youtube subject tags will fit in *your* routers'
TCAM?http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-con
sortium-to-replace-tcpip
[ Can someone convince me this isn't the biggest troll in the
history of the internet? Cause it sounds like shoehorning DNS
/and Google/ into IP in place of, y'know, IP addresses. ]Cheers, -- jra -- Jay R. Ashworth Baylink
jra@baylink.com Designer The Things I Think
RFC 2100 Ashworth & Associates http://www.bcp38.info
2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It
By Name! +1 727 647 1274======================================== Murat Yuksel Associate
Professor Graduate Director Department of Computer Science and
Engineering University of Nevada - Reno 1664 N. Virginia Street, MS
171, Reno, NV 89557. Phone: +1 (775) 327 2246, Fax: +1 (775) 784
1877 E-mail: yuksem@cse.unr.edu Web: http://www.cse.unr.edu/~yuksem
- --
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
Hi,
How many Youtube subject tags will fit in *your* routers' TCAM?
http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
[ Can someone convince me this isn't the biggest troll in the history
of the internet? Cause it sounds like shoehorning DNS /and Google/ into
IP in place of, y'know, IP addresses. ]Well, you don't need addresses for clients, just for content... From the architecture page at http://named-data.net/project/archoverview/:
"Note that neither Interest nor Data packets carry any host or interface addresses (such as IP addresses); Interest packets are routed towards data producers based on the names carried in the Interest packets, and Data packets are returned based on the state information set up by the Interests at each router hop."
So it's basically suggesting a NAT-like table in every single router. And we all know how well NAT boxes scale...
We were writing in parallel.
-Murat
How often do the copyright owners on content give a flying fig in a
rolling donut about efficiency if it interferes with being able to
control who accesses the content, and how?
Look at the legislative history of attempts to fix the anti-circumvention
clause of the DMCA so it's not illegal to do technical tricks to access content
you have a legal right to access. That should tell you all you need to know
about the motivation for this....
The principle questions still stand unanswered:
What is the motivation for this? What do you gain? Does it create
some large architectural and performance in efficiency?How often do the copyright owners on content give a flying fig in
a rolling donut about efficiency if it interferes with being able
to control who accesses the content, and how?Look at the legislative history of attempts to fix the
anti-circumvention clause of the DMCA so it's not illegal to do
technical tricks to access content you have a legal right to
access. That should tell you all you need to know about the
motivation for this....
Thanks for validating for me that this is pretty much what John Schiel
said earlier:
Almost sounds like the perfect protocol to allow the combination
Internet/content provider to keep all content coming from where
they want the content to come from instead of the freedom to
choose
where the
content comes from.
- - ferg
- --
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
the pending interest table is more similar to multicast routing table,
which is maintained by end user subscriptions -- still challenging wrt
to scalability.
Cheers
matthias
As far as I understand, NDN's basic premise is to
install "names" into the network layer.
Hi Murat,
If they think names belong at layer 4 instead of layer 7 I can offer a
couple insights on how this might be used to make layer 3 cheaper and
more effective.
If they think names belong at layer 3 everyone in this forum can
rattle off a dozen reasons why that's totally wacko.
Just my opinion:
I just saw one video [1] so I may be misjudging or misunderstanding:
When posted in 2007 there were many open problems yet. I hardly think
that all the benefits would be real benefits and most things can be
already done and it doesn't solve the most intricate problems of today's
Internet. I wonder if it could really be fully trusted.
Sounds nice and all, but I'm having trouble constructing it in my own
head. What about live content (multicast), what about I as an end-user
being able to certify my own information without relying on someone
else? How to get the initial certificates, signed and trusted? When I
request everybody near me to get some info and nobody have it, will
everybody ask for everybody near each of them?
And besides, most of the problems he describes can be solved by
inserting a layer between 3 and 4 (something based on the Host Identity
Protocol and its DNS records). It's still a change of paradigm but a
smaller one: instead of connecting to hosts, connect to services that
can be provided (dig -t ESRV) by many hosts each of which may have (dig
-t AAAA) many physical addresses. You set up a tunnel with internal
signaling between end hosts that have multiple addresses and there you
go: automatic path resiliency on both sides, automatic L3 mobility with
connection persistency, some basic automatic encryption for all
connections among those two hosts, all without requiring PI addressing
(BGP would only be used for Internet providers and big sites)... It
would scale and all that is needed is some changes in the OS, not
applications, not the whole Internet. No need to justify equipment
acquisition because it is end-to-end. The infrastructure doesn't need to
be updated at first, but would need to catch up. Internet could be
forced to catch up and if done properly, this gives automatic efficient
addressing with a drastic reduction of the global routing table and
automatic BCP38. IPv6 could be an excellent opportunity to get this working.
[1] https://www.youtube.com/watch?v=gqGEMQveoqg
Best regards.