Hi everybody. Welcome to today's Protocol Labs Research Seminar. Today we are joined by Boston University Master Lecturer, John Day. John has been involved in research and development of computer networks since 1970 when his group at the University of Illinois was the 12th node on the ARPANET and has also developed and designed protocols from everything from the data link layer to the application layer.  So thank you so much for taking the time to join us today, John, and I'm going to let you take it from here. This talk originated some years ago during my crest to figure out how we got where we are. We really need to know how we got here in order to know where we need to go next. And so I'm going to try and stay away from as much of the history as possible, but there are a lot of myths out there and I will need to sort of dispel a few of them and sort of get the, you know, and there are some interesting early results that you probably aren't aware of. So, you know, let's start and figure out where this, how this whole internet work stuff started. As we just said, as you probably all know, you know, things started with the ARPANET and the ARPANET was the first packet switching network to be built. You all know that probably. And the whole idea was to do resource sharing. ARPANET figured that they could lower the cost of research if people, they didn't have to buy big computers for every site that everybody they were funding. And so, you know, and there was also stress, the idea that it was a heterogeneous network. And so, you know, in 1970, 71, there were 12 to, in those first few years, I should say, it was all planned. There were probably 12, over 12 different operating systems and machine architectures on the net. There were also places that were supposed to be compute centers, as well as places that were supposed to be database storage. But, you know, the ARPANET was really the first one. As you probably know, BBN was building the subnet. And it, what they came up with was actually very good for a first attempt. Necessarily, it was somewhere between a traditional Datacom network and a new packet switch network. But there were no layer diagrams at this point. In fact, I even checked with the guy who was in charge of developing the switches and they didn't do that. Now, layers, as you may well aware, came about in 1968 when Dykstra published his paper on the THE operating system. And it really captured everyone's imagination. I mean, people really sort of, you know, glommed onto this really all at once. Because in those days, elegance and the power of a solution mattered much more than it does today. And this really seemed to have, was an elegant solution, as most of Dykstra's were. Now, this, as they said, were not really necessary for the subnet because of how simple it was and what they were doing. Not all that simple, but it was, you know, no really. But the first thing, you know, that was necessary was, you know, when they brought the hosts on board, that changed considerably. And of course, since interfacing hosts to the network was something new. I mean, none of these computers had ever been developed to talk to a network. And there was a real question about how to do this. So the first thing we had to do was a device driver. And, you know, that was the host protocol. And just recently, Steve Veracher noted that one of the first things that he started thinking about when we were getting into this was, what were people doing with inter-process communication? What could they tell us about that? Because it was clear that that was the problem we had here. And they were going to build a resource sharing network. And then on top of that IPC facility, we would have terminal drivers and file transfer and all the usual things that an operating system would have. And that was all going along quite well. And very quickly, we all began to live on the net. It was amazing how fast that happened. But, you know, very quickly, there were new ideas coming from Europe. And there was some really interesting stuff going on. Soon after the ARPANET was operational, Louis Pouzan visits the US. Now, Louis had been on project MAC working on moldings where he had invented the shell. And Louis came over and determined that he was going to build a network in France. But while the ARPANET was a production network to do research on networks, Louis wanted to build, I'm sorry, it was a production network to do research on for the ARPA projects, not to do research on networks. Louis was going to build a network to do research on network. They called the project CICLOD and the switches were called CIGAL, which is of course Grasshopper in French. Their starting point in late 1971 was the first task was to determine what were the minimal assumptions that one had to make to have a basic network. Figure out what those were and then determine what else was needed to really support everything that was going on. Okay. By mid-1972, CICLOD came together and they had come up with some really new ideas. What was the minimal packet? Why assume it had to be sent on a fixed path, route packets independently? And they called this a datagram. Today we call this connectionless. They also reasoned that the host would never trust the network to be reliable. So why go to the extra work to try and make the network perfect, which was really counter to what the phone companies were doing. The host would require an end-to-end protocol to guarantee reliability and with no need for the network to be perfect, it would be cheaper, more resilient, and if it only had to make a best effort. They stepped back to look at the minimal requirements and found that for a data network, other than exploring congestion and routing, for now nothing else was needed. I mean, this was a huge revelation because what they had come up with was far simpler than what everyone else was doing. And it was truly radical because it was a non-deterministic, decentralized, reliable transmission with unreliable components. And this was truly a new paradigm and that constituted a problem. And I don't use that word lightly. This was a shift to non-determinism and to dynamic resource allocation away from what the phone companies were doing. And so just to review, the layers developed by Sue Claude were as follows. So of course, there was the physical layer and the wires, the data link layer corrupted packets and made it may do flow control. The network layer did relaying and multiplexing of datagrams with primary loss due to the congestion and rare memory errors during relaying. And then the end-to-end transport layer provided recovery and loss due, you know, those errors and loss due to congestion. And of course, that implied that the loss rate at the link layer didn't have to be perfect, but the loss rate had to be much less than the loss rate seen at the network layer. So the transport layer would be effective. And this was pretty much their design. Now, in 1972, with all that coming together, Sue Claude started a major program in collaboration with the University of Waterloo to do analysis of and simulation of routing and congestion management. It would, of course, be 14 years before the DARPA and the internet even realized that this was such an issue. Then they, you know, and then of course, they botched it pretty badly. We'll talk about that much later. Layers in the network here are not a decomposition of functions within a single system, but are distributed shared state across systems. And this was one of the things that Sue Claude really figured out. And it's something that's not that well known, that a layer is, you know, the most important property of a layer is its scope. Okay. Layer is a distributed resource allocator. Different layers have different scope. And that's what this is illustrated in this picture here. This is also why the concept of controlling data planes become untenable while it is a stack in the host. The other end of these layers are not in the same system. They aren't all in the same plane. The internet missed this, the importance of scope entirely. And it took us a long time to realize that they had, because for a lot of us, this was just natural. We saw this and just never barred up. We assumed everybody got it. But it was only later that we managed to realize they didn't. This new model had four characteristics. This was not an innocuous change, but a shift of axioms. It was a peer network of communicating equals, not a hierarchical network connecting a mainframe with terminal slaves. The approach required, as I just said, the coordination of distributed shared state and different scopes, which were treated as black boxes. There was a shift from largely deterministic to non-deterministic approaches, to some extent from Newton to Heisenberg, not just with datagrams and networks. But this is also the time when operating systems were making the shift from pole to interrupt driven. And there were also some physical layer things, like the development of Ethernet within about two years of all this, that was also non-deterministic. Those ideas were just in the air. This was a computing model, distributed computing model, not a telecom or datacom model. And that was really important. The network was an infrastructure of a computing facility. Now, 1972 was an interesting year. First of all, Tinker Air Force Base joined the net, exposing the multi-humming problem, at least for the Americans. In the ARPANET, your host address was your import number. Okay, it was the interface to the amp. And so consequently, in fact, I always tell the story, Tinker joined the map, my boss came in one day and said, they're joining the net, they want to take us at our word, they have two connections to the network. And I said, oh yeah, great, that's not going to work. Because to the network, that looks like two different hosts. But of course, a half second after I said that, I said, oh well, this is obvious. We've seen this problem before in operating systems. We need to route to the node, not to the interface. I thought that was obvious. And everyone saw it. It turns out that it wasn't so obvious. The ARPANET had its coming out party in 1972 at ICCC. They put an amp at the conference and did all sorts of demonstrations. The first meeting of NWIG occurred at ICCC 72, where CECLOD was introduced. And everyone had a great deal of interest in it. Everyone just was bowled over by CECLOD when they saw it. And the ARPANET MPL and others were involved in NWIG and it was finally chartered as an IFIP working group. It was clear that the key project would be to develop an internet transport protocol, which was going to be key to this new approach to doing things. They also did a virtual terminal protocol, which was a big deal then and also some more comfortable description techniques. And I can tell you more about what happened at ICCC later. Now, however, this small group, and it's probably hard for you to imagine, but I would even risk to say, I know it was much less than 100 people involved in all of this, and they were new to power politics. And what we were proposing was something like the CECLOD model was very radically different from what was out there, and also very different from where some people had a large, shall we say, vested interest. And a nasty brawl was shaping up with the phone companies against the computer companies and everybody against IBM. Remember, in these days, IBM had 80% of the computer market. Now, but they had their problems. Somebody once told me that IBM got to where they are because they sold to the guy who signed the check. That's very smart. But think about it. In 1970, 71, how much computer science, do you think somebody who could sign a check for millions of dollars when a million dollars actually was worth something, knew about computer science? Not much at all. And when I was told that, I said, you know, this means that as the field matures and people move up the ladder, it's going to be harder and harder for IBM to make a sale because they never had the best technical solutions. Of course, the dropping cost of computers just accelerated that. Of course, when I said that, they all said, hey, you're crazy. They'll never lose their place. Of course, by the mid-80s, they're laying off tens of thousands of people. But they also had a problem in networking because they had built SNA, System Network Architecture, which was, as everything with IBM, centered on the mainframe. Now, of course, the first rule architecture is you can always take a mesh network and subset it to be hierarchical, but you can't go the other way. And IBM knew it. They knew this whole new approach to doing networking was counter to what they had. Now, they were in a position because of antitrust that they couldn't really oppose it. The must they could do was try and slow it down, and which they were pretty effective at. The phone companies, on the other hand, used their architecture to determine who could define the boundary between them and the subscribers and who got to sell what. And there's another slide I could use that shows that, but two groups could have completely different views of the same equipment. But this was a might, but the cloud proposed a much bigger problem for them. First of all, for the French PTT, the cloud was a disaster. And of course, they had the PTTs had this dream that they were going to put services in the network. This became a code word. The many tell us, if you know about that as a good example of this, but they wanted to put essentially what Google and Amazon and stuff do today. They wanted to put it in the network so it would be part of their monopoly. They've never really given up on that. They keep trying to do it. Of course, having a transport layer sealed off the network to just moving the bits. They didn't like that at all. They kept trying to argue that there was no need for a transport protocol because their stuff was reliable. This was a big fight all through the late 70s and early 80s. And it was not helped by the fact that Puzan was rolling around advocating against the PTTs. I've talked to the guy who was Puzan's boss at area, and he was getting a phone call a week saying shut these guys down and we're going to cut your funding. It was getting pretty brutal. Now, you might think that, well, this isn't that much difference, but think again. In the bees, these were two entirely different models. In what I call the beads on a string model or the ITU model, boxes and wires are dominant. Layers are merely modules in a box and hosts are not really part of the network. If you tend to draw diagrams like this, you're probably thinking in the ITU mode. In the ciclode or layered model, processes and layers are dominant. Boxes are merely containers and hosts are part of the network. This is what puts a very different flavor on things. Now, one of the things I should have mentioned in the beginning I did was small differences here can make huge effects. And it's really interesting to see what some of those are. We've already gone past three of them. The first one actually occurred before the ARPA net got started. And I only came to this much later. It turns out that Bob Taylor, who was at ARPA, ran into Roger Scantelberry from National Physical Laboratory in Allen at a conference. And he happened to mention that ARPA was planning to build this network. And they would have many computers for the switches and probably run 9.6 kilobit lines between the switches. And Roger said, well, you know, we use 9.6 in the MPL network. And we really found it was too slow. You really should go for higher bandwidth lines. Now, I don't know that Roger knew what he was suggesting. But in 1970, 50 kilobit lines, which is what the ARPA net had, were outrageously expensive.  And, you know, having 50 kilobit lines in the MPL network, which was limited to the MPL campus versus nationwide in the ARPA net was a huge difference, at least in cost. However, it made the ARPA net a success. I really believe that if they had built it with 9.6, and probably none of you have ever experienced a living on 9.6, the ARPA net would have been considered, it would have worked. But it would have considered a curiosity, not really practical. But with 50 kilobit lines, it was a whole new world. And I think that was a real big difference. The other thing that happened here in these early days from the ARPA net's point of view was the US became fixated on the host as an important component of the network. And also for naming and addressing. And to some extent, they still have never really realized that when it comes to setting up communications, the host really has nothing to do with it. The third one is a lot more interesting. And it really shows, you know, how this can happen. The ARPA net assumed that the host had to be within 10 meters of a switch. Okay. On the other hand, Ciclod assumed that the hosts were not co-located with the switches. And in fact, we would be on customer premises where those switches would be on the network premises. And that they would be connected by serial lines. Now, the difference between the DOD largest and what was common business practice at the time is really telling here, because the ARPA net in the ARPA net host tells the amp to create a flow to another host. Whereas in Ciclod, the host maps to a network address and establishes the connection. And also Ciclod assumed that a host could be connected to more than one switch. Okay. Now, obviously, I mean, the ARPA net did relax this constraint later on, but it, you know, but the initial idea of the host was still now very much fixed. Notice this makes the host very much part of the network, whereas over here, the transport protocol had addresses, whereas this makes the host very much part of the network, whereas the host is not part of the network in the ARPA net. In Ciclod, replacing the serial lines with a network was essentially did not had no change. You add a relay on the transport addresses, and there's really no change required. And so by that simple expedient, the ARPA net was a network, whereas Ciclod was an internet architecture in 1972 and operational in mid-73. Now back to Enwick. The group got together and they were all, you know, very much, you know, the idea of moving on something like the Ciclod ideas. And they were going to do a transport protocol as sort of the key thing. Now, there were two proposals that were put forward. These are the document numbers, which they're known by, and much of this is taken from a very good article by Alex McKenzie. And another Enwick 61, which is based on the Ciclod transport protocol. And there was a healthy debate. Now, there were a couple of sticking points, you know, and you'll see, you know, you see how fragmentation works and whether or not it was a stream or letters, you know, that were maintained their integrity. And these were not really major differences. I mean, compared to the forces bearing down on these guys, this was, you know, this was not a big deal. After a hot debate, they weren't getting anywhere. A synthesis was proposed, and that protocol spec was called Enwick 96, again, the document number. There was a vote in 1976, which approved Enwick 96. And as Alex says, MPL and Ciclod immediately said they would convert to Enwick 96. The European Informatics Network said it would deploy only Enwick 96. They were just rolling out at the time. And then he says this, but we were all shocked and amazed when Bob Kahn announced that our researchers were too close to completing the implementation of the updated Enwick 39 protocol to incur the expense of switching to another design. As events proved, Kahn was wrong or had other motives. The final TCPIB specifications were written in 1980 after at least four revisions. Neither of these was totally right. The real breakthrough came two years later. After the announcement and DARPA was unwilling to compromise, the DARPA group goes off on their own. But the differences here weren't the most interesting thing about this event. The similarities among all three is much more interesting. This is before IP is separated from TCP. All three of the proposed transport protocols carried addresses. The TCP, early TCP, the Ciclod TS and Enwick 96. This means that the architecture Enwick was working to was this, an internet transport protocol of greater scope with addresses over multiple network layers with less scope with addresses and data link layers which might have addresses. If this doesn't hit you like a ton of bricks, you haven't been paying attention. This is not the architecture we have today. The Enwick model was this. An internet layer addressed hosts and internet gateways over several different networks of potentially different technologies. Okay. With different scope, different technologies, different addressing. Interdomain routing was at the internet layer. Introdomain routing was at the network layer. The data link layer had the smallest scope with addresses for the devices and hosts on segments it connected. That was their view. The internet lost a layer. Now let's set it back a minute. It was clear to everybody that the networks would have to be interconnected and there were basically two approaches proposed for doing this. The data com approach using protocol translation and the internet approach using an overlay with no translation. Of course, as you would expect, the ITU chose a data com approach or actually in those days the CCITT. Just hook them together and convert one to the other. Basically the same is how the PSTN works. For them, this was reasonable approach because it retained the traditional data com beats in a string model and was what they were familiar with. They were interconnecting relatively similar X25 networks. Protocol translation was feasible and wouldn't be messy. With no transport protocol that would relegate them to a commodity business, it preserved their business model. They were really gung-ho on this. The researchers, on the other hand, chose the internet working approach. Build a common layer over the different networks. The upper layer required at least a minimal service from the layers below. If not, then a protocol was required to enhance the network's service. The researchers in NWIG assumed that there would be a wide variety of potentially very different networks, raising the specter of messy complex translations.  The elements of the layer are cooperating to do resource allocation. This is a distributed computing model. Now, at the same time, while all of this was going on in the early 70s, ARPA had created a top-notch collaborative group that had learned how to work well together. The arguments that were had in the development of telnet and FTP and stuff were really pretty incredible because everybody came from different systems and there was different nomenclature. Over time, we figured out that we had the same things going on. We just labeled them somewhat differently or partitioned the functions a little differently, but they had gotten really good at it. In 1973, an attempt was made to finish that work by creating the user's interest group. What they wanted to do was really make the ARPA NAT a truly resource-sharing network with protocols to really enhance that, that will really move on remote job entry. However, I can talk about what came out of that, some of the stuff that came out of that. But anyway, fearing they were losing control, and actually to some extent they already had, ARPA shut down using in 1974. From then on, there is no talk of resource sharing and no new protocols developed in the ARPA NAT internet environment. DARPA withdrew to just do TCP, and by 1978 had separated IP from TCP when they should have been added an IP, but we're getting ahead of ourselves. With new people mainly, this is I think very interesting because as new people started coming in to the NAT, and it was an exciting time, it was incredible stuff going on. But the people coming in, the new people had telecom experiences, without the resource sharing emphasis, they saw what they were familiar with. A comment by Jeff Houston just two years ago really makes that clear. In an email discussion, he said, we originally constructed the internet as the computer-fect stimuli of the telephone network. When I read that, I said to hell we did. The phone system was the anathema of what we were doing. They were the opposite of what we were trying to do. So how did the internet lose a layer? Consider the networks for DARPA's internet.  BBN built the ARPA NAT, BBN built the amps, BBN controlled all that, everybody on the outside, it was just a black box. And they're building an internet, so they need an overlay across that. But the first three are not really networks, they're multi-access media. And with the common overlay, you get something like this, which should look familiar. This is basically what we have today. And there were lots of lands connecting to each other. The ARPA NAT is becoming less and less important, eventually a shutoff. This is not an internet, it's a beads on a string network just like ITU. We've met the enemy and he is us.  So the internet stayed with the data common approach. IP fragmentation is a protocol translation mechanism, not an internet mechanism. To be an internet mechanism, we'd have to put everything back together when it goes from network to network. By now, 1980, it's starting, and by January 1st, 1983, it's complete. The internet is no longer an internet, but an ITU beads on a string network. The term internet gateway has fallen out of use and replaced by router. We have a flat internet network. And they had help in this. IEN number 48, the cat and that model for internet working, had a couple of interesting quotes. Here, the idea that a host may have several addresses depending on how many nets it's connected to. In other words, they're continuing to name the interface. Tinker Air Force Base was six years ago. They should have seen it. And the other one was to simplify translation from internet addresses to local addresses. It is advantageous, if possible, to simply concatenate a network identifier with a local host name. Addresses to create internet addresses. This turns out to be wrong. This makes the addresses path dependent, which, of course, to solve moldy homing, you don't want path dependent addresses. This was a really interesting result because it runs against our intuitions. We do this with file names, and it works perfectly well. But then, you know, when I was thinking about this, you know, you just go back and think about what mold is called a file name. They call it a path name. It defines a path. And what you need with network addresses is to not define a path. You need to define where, but not how to get there. And of course, the same document, the figures are quite interesting. They all look like this. There are no layer diagrams. So what layer did they lose? It's not obvious at first. At first glance, one might say the network layer. After all, the protocol is called IP. Removing the ARPANET, remove the network layer, everything else just dropped down. But IP addresses the interface, something in the layer below, just like the ARPANET addresses did. It's more like IP replaces ARPANET. At best, IP names a network entity of some sort. At worst, a data link entity. Actions speak louder than words. We conclude they lost the internet layer. Now, there's a much longer lecture that goes into addressing. But, you know, naming the interface that derives all this from original work by Salter. Actually, Salter sees the problem, but then fails to actually take advantage of it. But what we actually have here, and if you go through it carefully, what you turn out is that because, you know, we thought Tinker made it obvious, the first thing we have is a mapping from the application names. We're following operating systems here. We have a mapping from application names to network addresses. John Shock made an early paper, a really nice thing of saying applications and application names indicate what you want to talk to. Network addresses indicate where it is and how to get there. So the directory mapping maps application names to node addresses. The node addresses, we find these where it is and how to get there by routing in the network layer. And then unique to networking, it doesn't really appear in computers, is that we can have more than one line between next tops. And in fact, in the 80s, this was probably common. In fact, it still is. And so then we have to choose which path we take to the next to the next top. And this is sort of what we see, you know, in addressing this is how it works. Now, one of the interesting things about this analysis is that this last mapping here and here are the same mapping. They're mappings between nearest neighbors at that level, at that layer. So, you know, that's really interesting. However, in the Internet, all we have is point of attachment addresses, no as an interface, which is named twice once by the MAC address and once by the network by the IP address. We don't have node addresses and we don't have application names. You know, domain names are just macros for IP addresses. Sockets, I don't know if there's anybody old enough to remember this, but sockets are like jump or, you know, well known ports are like jump points in low memory. Was that something that early operating systems did that was really ugly? And URLs are named a path to the application. Yeah, so what? This works signed so far. Really? First of all, it's limited to a very rudimentary form of client server. It may as well be SNA. It's not really any richer than that. Scaling has always been a problem. Requires a global address space. Believe it or not, that's not a requirement in a full architecture. That's caused much greater complexity yet they're needed. God knows, you know, because of the broken network architecture. Can't solve moldy homing. With a full architecture, moldy homing is free. It's inherent, which also makes mobility a terrible mess. But with a full architecture, mobility is inherent. Nothing else is needed. No home agents, no foreign agents, no tunnels, no additional protocols. It just works. You can't, you can't open a connection to a specific instance of an application just to allow, well, you can, you can do it yourself, but the architecture doesn't support it. And you can't open a connections to specific instances of application applications with two different protocols. It's not supported by the architecture. It's like living in the 1970s. I mean, nothing's changed. Oh, I guess I've got a question for you guys. We got this module there and there's a need to partition it into two modules. The question is, along what lines do we partition it? One could partition it one way, but it breaks some internal functions. Or we could partition it a different way and not break anything. Which do you think we choose? Well, I would choose the first one. I mean, I don't know. It's my pre-election. Then why didn't they do that for TCP? Spilling IP from TCP was a mistake. Separating error and flow control from relaying and multiplexing are independent? No, they're not. IP fragmentation doesn't work and never has. IP has to receive all of the fragments, retransmission, you know, et cetera. Oops, the wrong way. There is a fix, of course, an MTU discovery, the equivalent of doc. There hurts when I do this, well, then don't do it. And of course, you know, basically, TCP was split the wrong way. Research into the structure of these protocols shows that they cleave quite naturally between data transfer and the feedback mechanisms, data transfer control. And it's really great because this side over here is fairly simple functions with a very fast cycle time, and it just updates the state factor, whereas this side is more complex, has more stuff to do, reads the state factor, but other than that, these two pieces hardly ever talk to each other. This is a much cleaner separation of functionality. And so TCP was split in the wrong direction, and they failed to incorporate new results. As I said before, in 1978, Dick Watson makes a remarkable discovery. The necessary and sufficient conditions for synchronization for reliable data transfer is to enforce the bounds on three times. He assumes that all connections exist all the time and always have. State vector is merely a cache of state information recently. I really like how he puts this. He says that all connections exist all the time, that the state vector we have is ones we've received data on recently. If there's no traffic for two MPL plus A plus R, we can discard the state vector. Basically, the three-way handshake has nothing to do with why this works. It works because the times are bounded. Now, what he is in the ARPANET or in the internet, a connection starts at the M plus 1 protocol machine and goes to the M plus 1 on the other side. This combines port allocation and synchronization. What Watson is saying when he assumes all connections exist all the time is that port allocation and synchronization are distinct. First, you allocate the ports and then when there's data to send, synchronization occurs and it's bound to the port IDs. Not conflated in these two has significant implications. First of all, we can throw away the synchronization after there's no traffic for a while. The bindings are local. Many of the attacks on TCP connection establishment do not work in this environment. It's much more secure. It's much simpler. It's more robust and there are some interesting things we can do by assigning more than one connection to the same port IDs. They had a chance to get things back on right. In 1972, we knew that we needed something to map application names to network addresses, some kind of directory. Downloading the host file from the NIC was clearly temporary. When time came to automate, it would be a good time to introduce application names. Nope. We just automate the host file. Big step backwards with DNS. It's barely is macros for IP addresses. And then there was the API.  In 1975, when the first Unix system was put on the net, the API was Filio. Open, close, send, receive. Notice that this would lay the groundwork for a seamless transition to application names and eliminate well-known ports. Not only that, but applications wouldn't have to be modified to use network. And this also puts the name look up under the layer of boundary where it belongs. Instead, we've got domain names and sockets which exposes too much of the internal machinery and requires any application to be modified. Actually, I've heard that transitioning to IPv6, Microsoft was delayed by two years simply because they had to rewrite everything to deal with sockets. Then in 1986, they had congestion collapse. They were caught flat-footed. Why? Everyone knew about this. People have been doing research on it for 14 years, and there had been conferences on it. Now, congestion is a statistical form that occurs in any layer that relays and is contentioned in a point-to-point or multi-axis layer. Load merely increases the probability that there's congestion. The effectiveness of any congestion management scheme deteriorates with increasing time to notify. Put-again transport maximizes time to notify. It works by causing congestion. I mean, the current solution does, maximizing retransmissions. I mean, since when do you do congestion control by causing congestion? Towards any efforts to do quality of service, while people are trying to smooth out the traffic in the network layer, the transport layer is pulsing it. Implicit detection, i.e. lost packets, makes it predatory. Reaction to congestion in one layer can't be limited to a single layer. As near as I can tell, this makes this virtually impossible to fix. Whereas if you had an internet architecture, then clearly congestion control goes in the network layer, which is what everyone else thought. Time to notify can be bounded with less variance. Explicit congestion detection confines its effects to the specific network and to a specific layer. Did we know better at the time? Yes, Ross Chains work in 1988 and already shown this. He also proved that notification should begin when the average queue link is greater than or equal to one. This would make congestion and retransmissions very rare. Be good to manage the network. And they did a bang-up job with SNMP. I'm going to skip over this. Basically, the big thing here was that, first of all, SNMP was probably the worst protocol I could have done. We'd already tried it in 84 and realized that it was too much overhead. And so we had moved to a more object-oriented approach with both CMIP and HEMS. However, the real problem came when the SNB came out. The router vendor said, oh, this would be okay for monitoring, but not for configuration, because it's not secure. Well, SNMP was in ASN 1, which I always thought was an encryption algorithm. They thought you should just open a telnet connection and send passwords into clear, which is clearly a lot more secure. IPv6 still names the interface. We've known about this problem at this point for 20 years. No multi-hauling implies cluges for mobility. And notice the internet architecture, in an internet architecture, this is straightforward. They were actually convinced that routing on the node address wouldn't work, which just baffles me. And then we had the whole debacle that led from IPv7 to IPv6. And in 1992, there was more IPv7 deployed in the net than IPv6 in 2014. This was already over. By that time, the time of IP and G, tradition trumps everything. When they can't ignore it any longer, they get post-ITV and G trauma, and they look for worker rounds, and a deep thought yields loc ID split. In other words, they had the bright idea that we'd been overloading the semantics of an IP address with both locator and identifier semantics. First of all, Salser in 1977 defined resolve as in resolve a name as to locate an object in a particular context, given its name. In computer science, all names are locators. All locators are identifiers. You can't do one without the other. This is a false distinction. Second, the locator is the interface, not the end of the path. We're back to the same old problem. And third, the routing research group found that the flat identifier had to be aggregatable. So this was really a low-glow split. I mean, this stuff was just crazy. Fourth, research has looked at 15 different loc ID proposals, none of them scale. The problem isn't separating location from identity. The problem is and always has been separating physical location from logical location. But to do that, the layer is missing. You never get a busy signal on the internet. In 2010, they discovered buffer bloat. What a surprise. With plenty of memory of the NICS, getting huge amounts of buffer space backing up behind flow control. Well, duh, what did you think was going to happen? This stuff's got to go somewhere. If pure flow control in the protocol is pretty obvious, one needs to have flow control across the interface as well. Actually, if they had adopted Jane's solution for congestion control, buffer bloat would never have occurred. What about security? Don't you know? We read the papers? It's terrible. This is a big problem. And everything is being done after the fact. And we all know about what it means to retrofit security. What about the application layer? Well, what about it? There are applications, so what? Well, if you say so. Remember this? Remember how CICLOD got to it? The internet thought all error and flow control was at the edge. But that was HTLC, which does error and flow control, end to end, just different ends. They saw datagrams and best efforts as it ended themselves, whereas CICLOD knew that datagrams and best effort were just the beginning. They were the minimal assumptions that worked for them. They knew that there would be others. Taking stock, the internet has botched the protocol design, botched the architecture, botched naming and addressing in the API. When they had an opportunity to move in the right direction with application names, they didn't, they did DNS. When they had an opportunity to move in the right direction with node addresses, they didn't, they did V6. More than botched network management provided no direction in application layer. Botched congestion control, so bad it probably can't be fixed. Botched security, by my count, this makes them 0 for 10. Defies reason. I mean, what are these guys got an anti-minus touch? But it's a triumph. That's what they all say. But that argument so was DOS. But it works. You know, you point out all the technical flaws, and that's the only answer they come back with. So did DOS still does. As long as fiber and mortar's law stayed ahead of internet growth, there was no need to confront the mistakes, or even admit that they were mistakes. Now it's catching up to us. Fundamentally flawed from the start to the dead end. Every patch, and that's all we're seeing is taking us further and further from where we need to be. Want to feel really bad? A recent book, actually just came out in the last few weeks, paints a very different picture. First companies in the 80s were developing land products, then products to connect lands together in the workplace, then connecting lands over distances to create corporate networks. But in the late 80s, corporations wanted their suppliers to own their networks. The next step would have been so many corporate networks wanting their suppliers to own them. It would have been some pushbacks from the suppliers to say, hey, guys, we can't be on all these different networks. We need a common network. Not only that, but the medium-sized companies couldn't afford a corporate network. So they needed a common network as well. So all of this was headed in the right direction. This was moving toward the inwig model that we saw in the mid-70s. And then in the middle of all this is dumped free software in a subsidized ISP, but with a flawed architecture and lots of hype. The meddling of big government caused the entire mess. How do I know this would have happened? Because it did. It was the computer companies who were doing the OSI stuff. And they knew they'd have to accommodate different networks. And one of the things they were concerned about was what would happen if you had to communicate between two high-quality networks over a low-quality network. Well, you'd have to enhance it. There are actually figures like this in the OSI reference model. So they subdivided the network layer into three parts. The lower part being, quote, the network layer and the upper part being the internet layer. And so you end up basically back at the inwig model. And actually, this is really confirmation that inwig was right all the time because I was around with both of these and there was no overlap in the two groups. So OSI has an internet architecture. The internet has an IT-like network architecture. You just can't make these up. Just for old time sakes, we find that OSI didn't lose a layer, had a full addressing architecture, including application names and more, still needed a directory. X500 was not the answer. Adopted Watson in TP4, making it a major advance over TCP. Deckwood approved Jane's work for congestion control. Had a reasonable API that could have been improved a little bit but was on the right track. A security dendem and work was ongoing in the layers to do security. Major advances in the application layer and modular and recursive application layer with more to explore. Soon we go back to OSI. Heaven's no. Major advances since then. There's been a lot of cruft stuck in the OSI stuff by the ITU that would all have to be removed. So now what? The search for future internet was doomed from the start. There was no overarching plan to ensure the pieces would fit together. They thought it was all about requirements, which was really face saving. It had to be about the mistakes, the about the flaws. Just because it doesn't work doesn't make, just because it works doesn't make it the right solution. Whereas the mistakes distorted the proposed solution. The flaws had to be fixed and fixed correctly. Otherwise, we were building on sand. Good enough is only good enough in the short term. Good enough adds complexity. And the complexity it adds is not linear. Now what? Well, that's what we'll talk about next time. Thank you again for joining us today, John. Had a great time.


Live from San Francisco, it's theCUBE. Covering IBM Think 2019, brought to you by IBM. Good afternoon, welcome back to theCUBE's continuing coverage of IBM Think 2019. I'm Lisa Martin in Saugie, San Francisco, with Dave Vellante. Hey Dave. Hey Lisa, we're staying dry though, for the most part. Exactly, there are, there are, looks like the Moscone North is maybe having a few little areas of improvement that they've just running water through the pipes, as we would say. Just a little trial run. That's true, that's true. So we're welcoming back to theCUBE, a guest that hasn't been with us for a while, Paul Zocopoulos, Vice President of Big Data Cognitive Systems at IBM. Paul, welcome back. Oh, thank you, and thanks for getting my name right. That was good, very good. Oh, you're welcome. Phew!  I stalked you on Twitter. 19 books, over 350 articles. I know you do a lot of speaking. You've been at IBM a long time. This event's massive, right? 30,000 people or so yesterday was standing here only. In fact, they shut the doors to Judy's keynote because there were so many people. I'm curious, some of the announcements that came out with Cognitive yesterday, what are some of, last day, what are some of the things that you saw yesterday that kind of piqued your interest? Well, the Watson anywhere was, personally I've said that's a long time coming. I mean, come on, we've got to have Watson on any cloud, right? Not just the IBM cloud. So that was, I thought, a big deal.  I think there were 20 plus services. So, you know, kind of vogue. You know, we're in this multi-cloud world. I need a way to get to hybrid. So, those are two standouts. So your group's been busy, basically. That's right, that's right. I mean, you hit it, right? Watson anywhere, cloud everywhere. So it's about AI and that journey. I have to tell you that, when I hear all the announcements, there are tons of them, right? One of my favorite ones, probably doesn't go as noticed. And it was Watson Machine Learning Accelerator. And that is really about looking at the journey for AI and clients over the next course of the years on that journey. See, most clients are just getting started. There's some clients in the middle phase, and there's some clients now that are hitting what I call the enterprise-worthiness stage of AI, right? And so when we look at our announcements, they're actually taking you from just getting started all the way to enterprise-hardened, explainable, interpretable algorithms, and how to manage that. Because we're going to go from this world where AI is sitting in the corner offices for the privileged few, and we have to democratize for the many. But today, it's like, here's a little data science team, they have their own server. Here's an R programmer on their laptop, you know, and hanging out working there. But we want to bring this all together for enterprise. So things like workload management, which is what Watson Machine Learning Accelerator really does, is how do I get everything together and working in a concurrent environment as organizations go from having 10, 20 algorithms to trying to deploy thousands of them. That's how they'll define themselves.  But the fact is that if you can operationalize AI, you can open it up to a lot more people. You know, as a line of business person, you'd much rather not have to go to a data scientist every time you want to do something with AI, because otherwise you're just kind of repeating the old decision support world. So what are you guys doing to operationalize AI? So it's a great question. We're taking the friction. And so a lot of people come and say, oh, GPU acceleration. So yeah, it's about training stuff faster. It's an open architecture and power. And so you've seen the work with NVIDIA and that's unique to what NVIDIA can do with our cognitive systems is to accelerate the CPU-GPU communications. But there's a broader pipeline when you go to this AI journey and we want to flatten that curve. So one is how to get up and running. And I don't know if you remember, open source changes all the time. So we're enterprise hardening, back testing, getting you ready for here's the platform to deploy, built on open source. And where 80% of a data scientist time is spent right now is in what I call data preparation. Wrangling data, labeling data, get stuff together. Now none of that is data science. It's like none of that is data science at all. And that's where the time. And once I get the data ready, I train the model. Okay, so you've heard a lot about that. And then the next thing I do is have to optimize the model. So I think about where data scientists should be spending their time. And that's on stage four. And we call that exploring the hyperparameter space. Another thing that Watson Machine Learning Accelerator is all about, how do we make the model perform? Now for data science geeks perform means how well is it classifying or how accurate it is. Hardware people often think performance means how fast you go, right?  So we're looking at all five of those stages. And one of them, the biggest one is at 80% sync time. We're trying to drop that to 20% and open it up for the rest of the enterprise. So how do you democratize AI? You mentioned that a lot of enterprises are really at the beginning of that journey. But when you're out talking with customers, is there some sort of paralysis there where they're like, Paul, where do we start? Right, right. I think there's two areas where I see inertia or friction. So one is where do we start? So let me say that. Start with the data you have. You don't have to step up to the plate and hit a home run. You just get started and it's the things, the little things you do every day, not the big things you do once in a while. And we always hear about disruption. Disruption, you hear about Uber and Airbnb as the disruptors. I actually believe they were the disruptors of yesterday. I think right now, we're in this list shift, rift or cliff moment. The disruptors of tomorrow will be those at the head of the analytics renaissance that work with the data they have. We know the outcomes, we call that supervised learning and that's where you get started. And then the other piece is, how do I get more people to participate? Talk about the lift, shift, rift or cliff intersection. I saw that you've talked about that on social media. Can you break that down a little bit more and also talk to us about how you're helping customers actually kind of break through that or maybe it's avoid that altogether? Yeah, well, I mean, you want to take two of those four and not take the other two, right? And I think that we do this lift, shift, cliff moment in two ways. One is as individuals. So the people in the audience, the people watching here, all of us as practitioners, we have got to get our skills moving forward. I always say skill years are like dog years, right? Like they age instantly. And so you should be waking up every day like a newbie in this world and learning every single day. And if you do that, you'll have nothing to worry about as an individual. And as organizations, you had better put analytics at the forefront. That means from the boardroom, that means we encourage the culture of analytics everywhere. And so that's what I mean by lift, shift, rift or cliff moment. So it comes back to sort of opening it up for average everyday line of business people. You got to demo. I'm trying to see what you got here. Can I show it to you? Yeah, please. All right, so you were talking about the data scientists and citizen data scientists. So I'm going to propose to you this thing I call the wisdom of the crowd, right? Today, data scientists have to build things they're not domain experts. Imagine if I could invite the many to participate in this storyline. And in the storyline, everyday line of business people could create an application based on an idea or a model, and maybe we'd have thousands of them. And out of those thousands, we might vet, I don't know, 50 or 100. And out of that, we would team up with data science, deploy 10 or 20 into production and then do the whole thing over again. So let me show you how I could create this application here without building a single line of code. And I actually use you, Dave, as an example, because I wanted to see how much face time you get on the cube when John is up here with you doing. Oh, I don't need AI to tell you that. Oh, you don't? I can give you the answer. So I had this. I got the short end of the stick, and I'm not one to pull it. Well, we'll let the data tell the truth. Okay, let's see what happens. Yeah, that's data driven, right? So I had this intuition as a line of business user and I went to explore this. So you can see here that we'll have two videos here. And on the first video, you see where I put this here? We'll say host screen time. That's actually going to measure the amount of time that you're on screen. And I would build that. And I actually built that in this modern way that democratizes for the many. I'll just start it out here. And on the bottom, I built it the old fashioned way. So you can see we got John in there and they start out pretty good to start, right? They're both recognizing both of them. So let me go and pause these. Now, the first thing you should notice is I've got a timer on the bottom. I got a timer on the bottom because I actually had time to build that. My DevOps team kind of put that in there for me. So we'll continue this. Move it over here and let these things run. Now, look at the accuracy of these models. Do you notice on the top, you guys are both identified increasing the screen counter and on the bottom, I can't see you. So computer vision is very interesting. If I wanted to teach a computer to tell me what the number eight was, I could show it a picture of an eight. But the moment I moved it sideways, it would have no idea what it was. I need to train it with lots and lots of data. And so the bottom is the way the data scientists work. So what did I have to do to do that? I had to go collect some video, had to reformat it, had to put it down to a 480 and I had to write some code far away. And you see the code there? Now, in order to get just to MVP, so this model clearly doesn't score well. Dave turns his head and it doesn't know who it is anymore. All I said is you're Dave Valente and if you're not, then you're John. So what do you do if you've got a third person in there? All right, and this is where we democratize it. So this is our PowerAI vision. We've been talking a lot about this and I want to kind of invite everybody to take part in this kind of data science renaissance. All you do is you would go and upload some video here and you go capture some frames. We could auto capture those frames every five seconds. And let's say I wanted to add a new person like Arvin into this list here. And so I want to go develop and figure out how the algorithm can find out Arvin is. Now in my last demo I showed you that was a linear classifier, that wasn't easy. Here we'll go type in Arvin, add Arvin. And then I'm just going to highlight it and box Arvin. And now I've started to train the model. There's no code at all. You just trained the model. You just said this is Arvin, when you see this. So I'm labeling the model and then I'd have to go set it off to training. And now look, I'll do one other thing for you here. I'll go and say, well here's the think logo. And maybe I want to track some logo detection. That's it, that's how I built the model. Now it's all about how much supervised label data you have. So that's why I said who are the disruptors of the future. And that's all about the compute power and the workload management power to train this stuff. So Cognitive Systems is really all about both. So we obviously know about the power and the workload management. How do I go and actually generate the data? So once I train this model, I could click auto label. It'll actually go through the rest of the video and go and find out from what it saw. But here's where things get beautiful. And everything I've showed you is someone writing lines of code, now replaced with a clicker. So I click augment data. We call these morphological operations. I want you to notice something. We have 119 images labeled of Dave and John. So as I click here, I'm going to apply these morphological operations, Gaussian blur, sharpening blur. That all means stuff to data scientists. Now I have 4,249 data points. And I will generate that automatically. That's all driven by line of business. And finally, we can come over here and go actually look at the model. Here's my model. This model is actually scoring pretty really well. But even if it wasn't scoring well, I'm at 70%. This is now when I pass it to the data scientist team to do what they're exceptional at, the tuning, the hyperparameter tuning for the performance score of the algorithm. And so here, I'll just finish this off by, I think I had a picture of you. I'll just drag it in here. And now it's actually going out and scoring it. We're scoring at 96% accuracy. And I can expose this as a rest of API with the click of a button. So I just have one thing though I found out with the AI for you, Dave. At the end of it, from what I can see, John is getting about 50% more screen time than you. And if- That's all, that's pretty good actually.  And if you notice your name here is Dave Dapper-Velante. Cause we can't help but notice, we can't help but notice how well-dressed you are. You need a data scientist to put that in. You're well-dressed, it is pretty accurate. But you're not getting the ROI on those outfits that you need for screen time. That's what we found with AI. It's tough with my business partner, John. But that's pretty cool. Now, you're saying you wrote the code, right? To identify either John or Dave. And at what point did you bring the data scientist in? Yeah, so I didn't write any code on the top. On the bottom, which the model did not perform well. When you turn it inside, we couldn't see you. That's the code we wrote. And that would take iterations, iterations. There was no code written there. We built the model.  Which was a couple lines of code. Took him about half an hour. And in this case, I didn't really bring the data scientist in yet. Because I'm scoring it 96%. But I can easily pass it on in the workflow. And that's the story. It's a pipeline workflow across. So I'll pull the data scientist in when I need to. But 96% accuracy without a data scientist presence is pretty good. So a more complex use case, you might not get 96% accuracy. You might be at 50%, 40%, 70%. Now you bring the data scientist in for the last mile, is that right? Absolutely. This is only scoring 50%. And you don't think that's impressive. I think it's pretty impressive that I did that in half an hour. And now this is engineered from the wisdom of the crowd. I'm a line of business user. And I'd like to know what kind of screen time you're getting. Maybe that's at a sporting event. And I'd actually like a new business model where I charge Toyota by the second that they show up on the screen. That's my idea. Data scientist is never going to think that. I get it started and then they join the renaissance. That's how you democratize AI for the many. Yeah, so maybe you could talk a little bit about how, what was the compute power behind this, the infrastructure behind this? And then maybe we could talk about power and how you're applying that for AI infrastructure. Yeah, that's a great, great question. So the bottom video actually trained on my laptop. It ran for about a day and a half just so you know it was saying it is my laptop. On the top of the video, we actually leveraged our power AI architecture and ran that through with Watson Machine Learning accelerator. And I got to tell you, the models train in about 30 minutes. And in fact, we had trained a model on your last show with your last guest in the amount of time when you finished to when I came on stage. 20 minutes, yeah. So I mean, that's the accelerated compute. And it's not, and I hope what you're seeing here, this isn't just a hardware componentry story. This is a kind of coexistence in an almost synergy of software and hardware together. And that's what's needed in the AI era. Well, it's interesting. I know when you guys changed the name of the power systems group to cognitive systems, it had, you know, I inferred, of course, we got a guy running it who used to run the software business of a big software component. So it is clearly more than software. What are some of the sort of more interesting use cases that you guys are seeing with clients, specifically in terms of operationalizing this? Yeah, for sure. So in use cases of AI is, I think we're in this world of precision. So we're in precision agriculture, precision risk or underwriting, precision finance, precision retail. So the use cases are everywhere and it's really taking in all this kind of data. In the operationalizing, I think that we're helping people on all the levels. You think about it, I almost see three segments. The first segment is, we're not really sure what to do. This AI and everyone says they're doing AI, reminds me of the Hadoop days and the big data lake and you know how all that stuff turned out. So how do we get you started so you can get down the path and build kind of MVPs? And that's what I just showed you is the MVP. The next group of people are folks that have maybe one or two models deployed and now they're trying to say, how do we scale out to hundreds and thousands of models? What is the path now to make this bigger? Cause we got it moving here and then the final phase with few people are at are those who are getting the challenge of I'm getting to a thousand algorithms deployed and now how do I get all this stuff running? And so that entire path goes like this and our storyline goes across that entire path. How unique is this in the marketplace? I'm interested in your commentary on IBM's competitive advantage. Is this the only guys who can do this and why are you winning in the market? How differentiable is this? Yeah, so I think I'll answer that in two ways. One is from the brand in which I participated in a larger company called IBM. In terms of the acceleration, there's nobody doing what we're doing and the reason is you took this kind of power processor and created the open power project. And just like software evolved through open innovation, that's what hardware has done. So you look at Mellanox and NVIDIA. So I'll give you an example, Dave. The NV Link exists on Intel and exists on power but they operate in two very different ways and nobody realizes that. So NV Link accelerates GPU to GPU communications. Does that in Intel, does that on power? But because of open power, NV Link also allows the GPU to talk to the CPU. So GPUs accelerate AI training cause there's thousands of cores there, right? But they still got to talk to the CPU and on top of that they don't have much memory. So there's an example that's completely unique in the industry to make you train faster. I think our workflow model is completely unique. The tools that I showed you and around the workload management and then you look at the bigger part of IBM and how I can mix this with API calls to clouds, cloud based Watson services or local. But on top of that is now it's about how do you build the data that you can trust and how do you look at things like the explainability of the model with their Watson open scale and that kind of stuff. So it's a bigger story and nobody else has that end-to-end story. Well, and it's showing up in the results we saw last quarter that your line of business was a bright star, you know, we're seeing some momentum. Obviously there's a lot of activity going on in Linux.  So congratulations on that, it's exciting to see. And of course maybe a lot of people might not realize that when you guys did the work to bring in little end-to-end compatibility you can run an entire software suite now. That it's not just this sort of niche proprietary platform anymore, it's mainstream. And so it's starting to show up in the business results. So that's great to see. Yeah, when I say democratized for the many I mean for the people, for the enterprise and across the entire spectrum. So. Well, Paul, thank you for confirming my suspicion here that John is my partner, John Furrier, sucking up all the camera time. John, I'm going to have to elbow my way in a little more. So appreciate that. Having the data, John's very data driven. So appreciate that. And it was good to have you on. Yeah, it was nice to see you again. All right, keep it right there, everybody. We'll be back with our next guest. We're live from IBM Think 2019. You're watching theCUBE.


Good morning to all of you Welcome to this launch of train 10,000 librarians program under the national virtual library of India project that isn't short and we ally of ministry of culture You all know that Under the national mission on libraries, which was launched in February 2014 one of the major components of the mission was the Setting up of national virtual library of India The other three components that were there one of them was capacity building of librarians. The third was Conducting survey of public libraries and fourth one was setting up model libraries in states and districts Capacity building is one of the major components in fact and already the Raja Ramon library foundation. They have been Conducting regular bases face-to-face workshops in different centers to train the public librarians Now this is a Special moment in fact when we are going to launch a program in which actually we will be at a time able to address Large number of librarians in a go This is a one-day program and it will be a whole day program and the VR starting with Basic module that is on Koha as you all know Koha is an integrated library management system And it's very important when the libraries are going for automating their libraries They need to know the basics of Koha So you will be actually trained throughout the day on how to use the Koha software So we are pleased to have with us in our studio the vice-chancellor of Indra Gandhi National Open University Professor Nageshwar Raoji. I welcome you sir for this session. I We also have with us Professor Kannan Maudhulia The main PI of the NVLI project from IIT Bombay So to start with I will first request Professor Kannan to tell us about the workshop and how we plan to go about the whole day Thank you, Professor Kanjilal I'm happy to address you again. We had a brief interaction before this program I'm happy that there are 100 remote centers connected and More than 2,000 people. I think it's about 2300 as of yesterday There were 2300 people and there are likely to be some spot registrations also I'm happy that close to 2,500 people are listening to this that we can make this program available to So many people Let me give a brief background to this method There are two or three Types of technologies that are being used in this workshop. One is The usage of this platform called T10 KT train 10,000 teachers platform That is being modified here as T10 K L train 10,000 librarians. So what is this T10 KT? So this was the program started by The National Mission on Education through ICT MHRD Government of India It started as train 1000 teachers. This program started in 2009 And at the time we had about 30 40 centers and The program was very successful Then the MHRD The mission enemy ICT encouraged the PI of the project my colleague professor Fatak to Convert it into a 10,000 teacher training program and So it became T10 KT through that program a Large number of college teachers were trained Mainly on engineering subjects Something like 1,80,000 teachers were trained through that program the target of the that project was to train one and a half like teachers so 1.8 like teachers got trained each one undergoing two-week long program typically Course that is done for a whole semester in an engineering college for example in IIT IIT Bombay and IIT Kharagpur were partners in that T10 KT an Important technology used in that was also developed as a part of That project. It is called a view it was developed by Amrita University and Amrita University Developed the software a view which has been which is now a great software for two-way audio video interaction it allows 100 remote centers to connect with each other See each other's discussion The way it is done is there is a teacher note who At which the expert answers a question raised from One of the remote centers wherein somebody might have a question These two namely the person who's asking the question and the person who's answering the question Are seen on the video for everybody to see one of the problems in synchronous Education by the way, this is synchronous education because whatever I speak all of you are listening to me simultaneously One of the problems in scaling up synchronous education is what if there are a lot of questions? Fortunately if only everybody can see the discussion on a particular question Then all such doubts amongst all such participants get resolved So you don't have to repeat them again and again. So that is a way to scale up So this is one technology Which is a I would say reasonably perfected technology It requires bandwidth If you have two Mbps connectivity you can connect The software is open source software Thanks to government funding Our taxpayers money is used so you can download you say thanks We started with as I said 20 30 remote centers now there are about 550 remote centers There are 100 remote centers that join today from 17 states There would have been another perhaps six or one remote centers had it not been for Tithili, okay, because of that some centers in Marisa cannot join spite of that we have a Good enrollment So this is one of the technologies we are using I would say this technology has made India small country Anybody from any remote center any part of the any corner of the country If only they have two Mbps connection You would see my presentation and I your question as if we are talking from next door as if we are neighbors, right? So the distances don't matter The reception is going to be the same Whether it is going to be in the remote center in Delhi because I'm I'm a digno Or it is going to be in Trivandrum for example Probably the farthest place from here or column for example the other benefit it has produced is It has empowered half our population In many of our short-term training programs, especially in engineering colleges We find mostly males attending because it is difficult for The head of the family namely the mother To come to IIT Bombay or to any other course For one week or two weeks and be away from their family This method allows them to complete all their work in the morning go to the nearest center Participate in the days program and go back to their families in the evening. I Would say that this method empowered Half the population We would like to make this available also to librarians So this is one technology. We are talking about namely synchronous technology the software the method of conducting web pages Conducting a training program for coordinators and so on. I would call all of this as one technology the other technology we are using in this workshop is Something called spoken tutorial. I'm the PA of that project It was also funded by the National Mission on Education through ICT and HRD We are happy to see to government To ministries working together to make this available The infrastructure we are talking about in all engineering colleges and so on on already Created through NME ICT Now the NBLI project is making it available for librarian training. We have created 10-minute long spoken tutorials on Koho. We have a total of 24 spoken tutorials Yes spoken tutorial is typically of 10-minute duration It started with IT training like C programming Java programming and so on and so forth Then it went to simulation topics It went to Sylab Python and so on now we are using the same method for Koho training A spoken tutorial is of typically of 10-minute duration Guaranteed for self-learning We guarantee it because we write a script for every tutorial It is not extempore like the way I'm talking now for every tutorial we write the script and We ask a beginner to go through it and certify that they can understand every step If any step is not understandable we return the script for improvement The script goes back and forth. I would say maybe about 10 times and Finally when it comes it's perfected then it is converted into a video through screencast It's a low-cost technology All you need is a laptop, that's all you need The 10,000 rupee laptop that we have launched is sufficient to record Using software called Kazam. You can also edit it using a software called Ked and live So you don't need studios. You don't need cameraman So it is created for self-learning then we dub this spoken part into all 22 languages We have a total of about I Think we just crossed about 1,000 tutorials in English and then including dubbing We are close to 10,000 tutorials. So it is available in every one of our 22 languages For example, even in Sanskrit we have close to 200 tutorials that in Hindi Gujarati Marathi Bengali Tamil and so on we have More than 600 tutorials already dubbed these cover Important topics. So we have made the same Technology available here The third and equally important Aspect of this methodology is that you can use it offline. It is possible to download an entire thing entire package for example One could say that I want see tutorials in English, Hindi and let's say Punjabi download it Or you might say I have Koha. I will download it also in English The whole thing will come as a zip file. You can take your own time to download it Once it is available, it can be unzipped Copied into every machine and the internet is not required. For example today, that's what is going to be done In every machine of yours That zip file is already unzipped and made available and the Koha software is also installed So in fact, you will open both of them side by side That is you will open the Koha software on one side on the other side. You will open the spoken tutorial You will listen to one command at a time. You will open one tutorial at a time in that tutorial You will open one command at a time. You will practice it if it goes if it works Go to the next command. If not rewind listen to it try it again It will always work because it is created for self-learning So you will go through the whole thing. So this is the second Technology spoken tutorial created for self-learning all the people who are conducting this workshop In your center, there are two people We conducted a coordinated training workshop for all of them That is in every one of the hundred remote centers. There are two experts one expert is the librarian Who knows how to Learn through Koha spoken tutorials He or she has already undergone the training at IIT Bombay in a coordinator workshop that we conducted on 29th of September There is also a System administrator from your remote center who also came to IIT Bombay on 29th of September To undergo training on how to install Koha Okay, so they already know that subsequent to 29th that is between 29th and today our team worked day and night and created new spoken tutorials on Koha installation Koha is a very elaborate software. You hear about it. I'm not an expert Professor Uma Kanjiral already mentioned Professor Manjunayaka the librarian at IIT Bombay also explained to you at the beginning During the interaction session It's an amazing software So it requires quite a bit of effort to install it Okay, and we have simplified it. It is all explained through spoken tutorials It is important for all of you to download the latest version Please do not rely on the Content that you took on 29th of September because subsequent to that we improved it As a matter of fact, I would say this is the fourth time. We are using these tutorials We conducted a workshop today workshop attack workshop wherein we tried some of our spoken tutorials Then we had one day pilot workshop to check whether our spoken tutorials are okay We became confident then we conducted a coordinator workshop and Then now we have E10kl. It is called train 10,000 librarians although There are not 10,000 librarians today. I'm pretty sure that we will reach that number There are more than 1,000,000 libraries in India including public libraries possibly even to lack libraries It is the desire of this Mission of this project National Virtual Library of India to Get all of you on board And one of the objectives of this mission also is to convert at least some select Libraries, maybe district level libraries public libraries as centers of learning So the mission is national mission on libraries is committed to that our project is going to Help achieve that and the ministry is very keen on that ministry of culture And so we would like to acknowledge all the help. I would also take this opportunity to Express my sincere. Thanks to Ignu and the honorable vice-chancellor for being Present personally to inaugurate this I would like to hand over the mic and I want to express my sincere gratitude For giving this opportunity At this amazing place Ignu. Thank you Thank you, Professor Kannan In fact, he has given a detail exactly how the project works and how this tutorials in future also We will be conducting in fact. So now to start with I think it's Time for requesting our honorable vice-chancellor to launch the program and give his inaugural address. Yes So, Kannan, IIT Bombay Maaji My dear friends It's a great day for all of us When we are trying to have this Koa workshop through this Online mode when Professor Kannan was speaking to all of you He has clearly elaborated the way through which we can use the spoken tutorial as Well as the Koa and if both the things they are being put In use in proper perspective you will get better results Till now IIT Bombay was very very popular With respect to the spoken tutorial project and we have seen that It has benefited most of us all over the country now with this Koa Our librarians the people who are working in the library they will be benefited Much more The way through which they wanted to have this sort of training It is also cost-effective Because if you see that at the time of registrations, we have to pay very very nominal sum And I think today also we have to pay some amount, but that is also very very nominal and back to from your place You can have this tutorial and you will get the best possible results one thing which has told to all of you is that The Material which is available to all of you. It is being updated on day-to-day basis Because the details which are available on 29th they've been revised four times till this Particular day So this sort of application you will find in this particular training program So that is also an advantage cost-effective you will get updated material and the best possible experts are also available That is the thing through which we are getting this Koa workshop and Reach is also very very wide. We are reaching to distant places distant people and that too One at a time because from here itself because we are reaching to so many people And that is why he has already told you that the Ministry of Culture has named it as the Koa T10kl T10kl So now this also helps us to understand He has also referred to the Amritha's AVU. That is also giving us good results now. Now, these are the newer ways to reach the distant learners and And this workshop will also help you to Look at the speaker but the speaker He can speak to you most comfortably even if you are a pseudo listener He cannot get you comfortably because he's not seeing all of you in that Shape wherein we kind we can see face to face when we interact with the Learners, we see that some of them are the pseudo learners and thereby our Speech it may be distracted. It will not be here when we go for this sort of workshop Where in we can interact with all with the same ease that the same comfort in which we want to present our Contents This is a great day for the Ministry of Culture Great day for IIT Bombay and great day for Ignu also because we all are Involved in this process and again I compliment all of you for taking this benefit of Having this sort of interaction and this learning this may help you to Look at your library in a much better way because this Koa software. It is freely available It can be customized also and you can get better results. So with these few words I Announce the launch of this Training workshop For all of you. Thank you very much. Thank you Thank you, sir. So press a condom would like to say something I would like to formally Acknowledge the partners in the NBLI project. There are three partners CDAC is the partner that implements the software Ignu is the partner which takes care of the data data curation IIT Bombay is the coordinating partner So we are very happy that we are able to Put together and make available All the resources that we have amongst ourselves to this important project The second thing that I want to point out is this The remote center the methodology that we are using is actually available for a lot of other things Although we started with engineering. We had conducted courses on environment and you know things like that now We are doing courses called College to corporate Even skills teaching skills communication skills and things like that So which is one of the things that when the platform was established the funding agency said that make sure it is available for Other purposes also it is being used similarly the generality of Sparking tutorials. We are now using sparking tutorials in the general area of health and nutrition one of the very important areas that we are working on is Training mothers on breastfeeding. We have a series of tutorials. We are also creating tutorials on Schools school level software So this mother tongue dubbing is going to be especially helpful to children who study in vernacular schools I understand because I studied in one such school So I just wanted to thank all the agencies I missed out some of the things because we had some discussion prior to this and I mentioned some of these So I thought I would repeat it now. Thank you. Thank you, Prasak Anand so for the vote of thanks normal food mood of thanks I would at First of all, I would like to thank our Honorable Vice Chancellor for his support and encouragement I think without that it would not have been possible at all and We have been actually working even for the Enveil I project under his guidance. So thank you, sir For all the support that we are getting The main lead in this workshop was a cannon mother earlier here He has elaborated exactly how we are going to go about and this is going to be a revolution In fact when we talk about the library is training I think no one thought about in such a large scheme. So this is going to revolutionize the whole process in fact and I'm also happy to inform you that with this workshop We are also becoming one of the remote centers of the project. So I would like to thank Prasak Kannan Mott earlier and all his team members some of them have come here and some some of them are available already online in the IT Bombay in fact So all the support they have been giving and we have been actually Collaborating with them and setting up the studio and other things. So thanks a lot for that support that you have provided us The function is being conducted from our electronic media production center. So I would like to thank the director of the center Shri Ravikandaji for the studio facility as well as the support electronic media support that has been provided by his team The whole team of EMPC And we have I mean I'm making it successful. So thanks a lot for the whole team I would like to thank the NVLI team from Igno In fact who have been supporting me and setting up the workshop in fact and Well, all kinds of support that I have been getting from them and last but not the least all the Participants available in the studio as well as remotely in other I think 104 centers You mentioned so I welcome you all again and also a big thanks to for being Registering for this workshop and being a partner in this whole process. Thank you. Thank you. So we will take a break now for tea Thank you. Thank you