RINA intro

1. The Pouzin Society
© John Day, 2013
All Rights Reserved
1
Welcome to the RINAissance!
An Introduction
to the RINA Architecture
IRATI RINA Workshop
John Day
Barcelona 2013
In a network of devices why would
we route between processes?
- Toni Stoey, RRG 2009

2. The Pouzin Society
© John Day, 2013
All Rights Reserved
2
Levels of Abstraction
(Abstraction is Invariance)
• Maximize the Invariant and minimize the discontinuties.
• Today there are essentially no levels of abstraction.
Reference Model
Service Definitions
Protocols
Procedures
Policies
Implementation
DecreasingLevelsofAbstraction
Invariant
Variable

3. The Pouzin Society
© John Day, 2013
All Rights Reserved
3
Unlike the Internet
• In RINA, most layers are private. This means that there can be much
greater variability in them.
– Here, there is much greater freedom and independence, but with the same
code base.
• The Reference Model, Service Definition, and Protocol Specifications
can be combined with off-the-shelf or custom procedures and policies
to specify a DIF.
• The concept of a public network is meaningless in RINA.
– There may be a public layer, but a public network is a non-sequitor.
• Groups may agree on common DIF specifications and policy sets.
– The focus is not on designing protocols, but on defining policies and
configuring DIFs.
• Maximizing commonality reduces operating and equipment costs and
improves management.
• Our goal is to make networks simpler, more predictable, more
manageable, in other words, more understanding.

4. The Pouzin Society
© John Day, 2013
All Rights Reserved
4
What Do We Mean by Invariance?
• An Easy Example: Separating Mechanism and Policy
– Big help
– Concept first proposed by Bill Wulf [1975] for operating systems.
• Separating what is common across solutions from what is uncommon.
• Mechanics of memory management are the same, allocation scheme or page
replacement policy is what varies.
• In protocols, there are a few mechanisms. Virtually all of the variation
is in the policies.
– Acknowledgement is mechanism; when to Ack is policy.
– This has major implication for the structure of protocols.
• We can apply this across the board to simplify and ensure that
cooperating layers behave in a compatible manner.
• Leverage is in the commonality, but letting what must vary vary.
– Never take it to extremes. It is subtle task.

5. The Pouzin Society
© John Day, 2013
All Rights Reserved
5
The Structure of Protocols
• If we separate mechanism and policy, we find there are
• Two kinds of mechanisms:
– Tightly-Bound: Those that must be associated with the Transfer PDU
• policy is imposed by the sender.
– Loosely-Bound: Those that don’t have to be.
• policy is imposed by the receiver.
– Furthermore, the two are only loosely coupled through a state vector.
• Implies a very different structure for protocols and their implementations
• Noting that syntactic differences are minimal, we can conclude that
• There is one data transfer protocol with a small number of encodings.
Tightly-bound
(pipelined)
Loosely-bound
(Policy processing)

6. The Pouzin Society
© John Day, 2013
All Rights Reserved
6
Implications: Protocols I
• Data Transfer Protocols modify state internal to the Protocol.
Application Protocols modify state external to the protocol.
• There are only two protocols (full stop):
– A data transfer protocol, based on delta-t
– An Application protocol that can perform 6 operations on objects:
– There is no distinct protocol like IP.
• Was just a common header fragment anyway.
• A Layer provides IPC to either another layer or to a Distributed
Application using a programming model. The application protocol is
the “assembly language” for distributed computing.
– As we shall see, we have now made network architecture independent of
protocols.

7. The Pouzin Society
© John Day, 2013
All Rights Reserved
7
Delta-t Results (1978)
• Watson proves that the necessary and sufficient conditions for distributed
synchronization requires only that 3 timers are bounded:
• Maximum Packet Lifetime
• Maximum number of Retries
• Maximum time before Ack
• Richard Watson develops delta-t to demonstrate the result, which has
some unique implications:
– Assumes all connections exist all the time.
– TCBs are simply caches of state on ones with recent activity
• 1981 paper, Watson shows that TCP has all three timers and more.
– Matta shows that delta-t is more robust under harsh conditions than TCP.

8. The Pouzin Society
© John Day, 2013
All Rights Reserved
8
Flaw in the Concept of Connection
(in both the Internet and OSI)
• In both, a connection starts in the (N+1)-entity and goes to the peer (N+1)-entity.
– This is a beads-on-a-string view. (In fact in OSI, was insisted on by PTTs)
• 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.
(N+1)-entities
(N)-entities
(N)-address
•
•
(N)-connection
Connection-
Endpoint
(port-id)

9. The Pouzin Society
© John Day, 2013
All Rights Reserved
9
Concept of Connection
Synchronization
Connection
Endpoint
Port Allocation
Port-id
Connection
• Instead delta-t works differently:
– Ports are allocated, then protocol machines create synchronization (shared state)
– And connection-end points are bound to the port-ids.
– We use the term “connection” within the DIF; “flow,” for the service provided
• Not conflating the two has significant implications.
– No traffic for 2MPL, connection disappears, but ports remain allocated
– Bindings are local. We will later see other implications of this.

10. The Pouzin Society
© John Day, 2013
All Rights Reserved
10
Implications of Watson’s Results
• No explicit state synchronization, i.e. hard state, is necessary.
• SYNs, FINs are unnecessary
• All properly designed data transfer protocols are soft-state.
• Including protocols like HDLC
• And One Other Thing:
• Watson’s result also defines the bounds of networking or IPC:
– It is IPC if and only if Maximum Packet Lifetime can be bounded.
– If MPL can’t be bounded, it is remote storage.

11. The Pouzin Society
© John Day, 2013
All Rights Reserved
11
The Connection Connectionless War
• The technical side of what was really an economic war.
– The Layered Model invalidated both the PTT and IBM business models.
– Connectionless removed the security blanket of determinism.
– The war created a bunker mentality that made understanding hard.
• All or nothing.
• For years, we saw it as the amount of shared state.
– Connections had lots of shared state; connectionless very little.
• A function of the layer, not a service. Not related to reliability
– Not visible over the layer boundary.
– Ports must be allocated even for a connectionless flow.
• Later it became clear that
– As traffic becomes more deterministic, connections are preferred
• Down in the layers and in toward the backbone
– As traffic becomes more stochastic, connectionless is preferred
• As one moves up and toward the periphery

12. The Pouzin Society
© John Day, 2013
All Rights Reserved
12
Resolving the CO/CL Problem
• Lets look at this very carefully
• What makes connection-oriented so brittle to failure?
• When a failure occurs, no one knows what to do.
• Have to go back to the edge to find out how to recover.
• What makes connectionless so resilient to failure?
• Everyone knows how to route everything!
• Just a minute! That means!
• Yes, connectionless isn’t minimal state, but maximal state.
• The dumb network ain’t so dumb.
• Where did we go wrong?
• We were focusing on the data transfer and ignoring the rest:

13. The Pouzin Society
© John Day, 2013
All Rights Reserved
13
So What Do We Know About CO/CL
• It is a function of the layer. Should not be visible to applications.
– Another mistake the Internet makes
• Connectionless is characterized by the maximal dissemination of state
information and dynamic resource allocation.
• Connection-oriented mechanisms attempt to limit dissemination of state
information and tends toward static resource allocation.
• Applications request the allocation of comm resources.
• The layer determines what mechanisms and policies to use.
• Tends toward CO when traffic density is high and deterministic.
• CL when traffic density is low and stochastic.

14. The Pouzin Society
© John Day, 2013
All Rights Reserved
14
Applications and Communication: I
Is the Application in or out of the IPC environment?
• The early ARPANet/Internet didn’t worry too much about it. They didn’t need
to. They weren’t doing any new application development.
• By 1985, OSI had tackled the problem, partly due to turf. Was the Application
process inside or outside OSI?
• It wasn’t until the web came along that we had an example that in general an
application protocol might be part of many applications and an application
might have many application protocols.
• The only known example of a political turf battle leading to a major insight!

15. The Pouzin Society
© John Day, 2013
All Rights Reserved
15
Applications and Communication: II
• The Application-Entity (AE) is that part of the application concerned
with communication, i.e. shared state with its peer.
• The rest of the Application Process is concerned with the reason for
the application in the first place.
• An Application Process may have multiple AEs, they assumed, for
different application protocols.
Application
Process
Application
Entity
Application
Entity
Inside the Network
Outside the Network

16. The Pouzin Society
© John Day, 2013
All Rights Reserved
16
BUT
There is only one application protocol
• Huh!? Think about it. What can you do remotely?
– Read/Write – Create/Delete – Start/Stop
– On various objects. Everything is just an object outside the protocol.
• Application protocols modify state outside the protocol.
• In that case, why do we need all this application-entity stuff?
– A particular collection of objects are required for an activity.
– May be shared with others, but has its own access control.
– One protocol, potentially shared objects, different state machines
– Hence, all application protocols are stateless, the state is in the application.
– And, we will see that this was the tip of the iceberg.

17. The Pouzin Society
© John Day, 2013
All Rights Reserved
17
A Quick Review
1: Start with the Basics
Two applications communicating in the same system.
Communication within
a Single Processing System
IPC Facility
Application
Processes
Port
Ids
A B
Application
Flow
This is establishes the API. The Application
should not be able to distinguish a slow
correspondent from operating over the Network.

18. The Pouzin Society
© John Day, 2013
All Rights Reserved
18
How Does It Work Now?
Distributed
IPC Facility
EFCP EFCP
FA FA
Application
Processes
Port
Ids
• Turns out that Management is the first capability needed to find the
other application. Then of course to do that one needs,
• Some sort of error and flow control protocol to transfer information
between the two systems.

19. The Pouzin Society
© John Day, 2013
All Rights Reserved
19
Simultaneous Communication
Between Two Systems
i.e. multiple applications at the same time
• Requires two new capabilities
Mux
Mux
EFCP
EFCP
EFCP
EFCP
EFCP
EFCP
• First, Will have to add the ability in EFCP to distinguish one flow from another.
• Typically use the port-ids of the source and destination.
• Will also need an application to manage multiple users of a single resource.
Op
Seq #
CRC
Data
Connection-id
Src-port
Dest-port

20. The Pouzin Society
© John Day, 2013
All Rights Reserved
20
Systems
4: Communication with N Systems

21. The Pouzin Society
© John Day, 2013
All Rights Reserved
21
A Little Re-organizing
So we have a Distributed IPC Facility for each Interface, then to
maintain the API we need an application over all of them to manage
their use.
IAP
DirFinder
A Virtual IPC Facility?
Res
Alloc

22. The Pouzin Society
© John Day, 2013
All Rights Reserved
22
Host Systems
Dedicated IPC
Systems
5: Communicating with N Systems
(On the Cheap)
By dedicating systems to IPC, reduce the number of lines required and even out
usage by recognizing that not everyone talks to everyone else the same amount.

23. The Pouzin Society
© John Day, 2013
All Rights Reserved
23
Communications on the Cheap
• But relaying systems over a wider scope requires carrying addresses
• And creates problems too.
– Can’t avoid transient congestion and bit errors in their memories.
• Will have to have an EFCP operating over the relays to ensure the
requested QoS reliability parameters
EFCP
EFCP
Interface
IPC
Processes
Relaying
Application
Relaying
PM
Interface
IPC
Processes
Dest Addr
Src Addr
Common Relaying and Multiplexing Application Header

24. The Pouzin Society
© John Day, 2013
All Rights Reserved
24
The IPC Model
(A Purely CS View)
DistributedIPCFacilities

25. The Pouzin Society
© John Day, 2013
All Rights Reserved
25
The Implications
• Networking is IPC and only IPC.
– We had been concentrating on the differences, rather than the similarities.
– Of course, there are layers! What else do you call cooperating shared state
that is treated as a black box? A waffle!?
• All layers have the same functions, with different scope and range.
– Not all instances of layers may need all functions, but don’t need more.
– As we will see, strong layering is better than soft layering.
• A Layer is a Distributed Application that performs and manages IPC.
– A Distributed IPC Facility (DIF)
• This yields a theory and an architecture that scales indefinitely,
– i.e. any bounds imposed are not a property of the architecture itself.
• But this also begs the question:
– If a layer is a Distributed Application that does IPC, then what is a
Distributed Application?

26. The Pouzin Society
© John Day, 2013
All Rights Reserved
26
That Wasn’t the Only Question
• Well Over a Decade Ago
• We Figured Out that Layers Repeated
• That Created a Potential Problem:

27. The Pouzin Society
© John Day, 2013
All Rights Reserved
27
Dykstra says Layers are all Different
• Once a function is done in a layer, it isn’t repeated.
• If you are going to contradict Dykstra,
– you better have a good argument, so . . . Better see what he said.
• The Layers of Dykstra’s THE Operating System
• (THE - Technische Hogeschool Eindhoven)
• “The Structure of the THE-multiprogramming system,” CACM 11(5) 1968.
– Layer 0 - Multiprogramming
– Layer 1 - Memory Management
– Layer 2 - Console communication
– Layer 3 - I/O
– Layer 4 - User Programs
– Layer 5 - Users (“not implemented by us” - EWD)
• Seem a bit dated, don’t they?
How Do You Do This . . .
Without This?

28. The Pouzin Society
© John Day, 2013
All Rights Reserved
28
A Few Days Later
• Musing about Dykstra’s layers:
– A bit arcane, but 1968 was a long time ago. Machines were far
smaller and much more resource constrained.
• We wouldn’t do those layers in an OS today.
• What would we do . . . .
– kernel, supervisor, user . . .
– and they all do the same thing!
• scheduling, memory management and IPC
– OMG! OSs are recursive as well!
• Of course this is what the virtualization fad has hacked into
without seeing it.
• That lead to
hmmmmmm

29. The Pouzin Society
© John Day, 2013
All Rights Reserved
29
Returned to OSs After A 30 Year Hiatus
• Knowing that the Days Were Over When H/W was a
Major Constraint and Distorted Possible Solutions!
– Now things could done the way they should be!
• But what I found was,
– Nothing had Changed. Still same old timesharing systems!
• No one Seems to have Noticed.
• What had Everyone Been Doing!?

30. The Pouzin Society
© John Day, 2013
All Rights Reserved
30
What I Saw
• Threads and Heap management were kludgey with all sorts of warts.
• They never answered the question, if a thread is the locus of
processing, then what does that make the “process”?
• Answer: The process is the OS for the threads. The OS is recursive.
• Hence,
– system ::= h/w isolationprocess
– process ::= scheduling memory mngt IPCthread*
– thread ::= process
• All Peripherals have their own processor and hence their own
specialized OS.
– There is no I/O, only IPC.
• For most OSs, IPC wasn’t there or something cumbersome.
• There were other implications and more to question . . .

31. The Pouzin Society
© John Day, 2013
All Rights Reserved
31
The Structure of a Process
• A Process has a recursive structure consisting of task scheduling,
memory management, and inteprocess communication to manage its
tasks, which are, in turn, processes.
Task sched
Mem
Mngt IPC
Tasks

32. The Pouzin Society
© John Day, 2013
All Rights Reserved
32
What Does a Modern OS
Look Like?
• It certainly isn’t a 70s timesharing system

33. The Pouzin Society
© John Day, 2013
All Rights Reserved
33
The OS is actually
a Distributed Management System
• A traditional OS is a heterogeneous DAF that includes the peripherals.
– The traditional device drivers are members of the DAF.
– In the case of the disk, it might have several members: one, looks like a
file system, one that looks like a database, and one that yields track and
sector access.
USB-DIF WiFi-DIF
OS - DAF
Printer Disk
Laptop
System

34. The Pouzin Society
© John Day, 2013
All Rights Reserved
34
The Basic Model
• A Processing System is everything in the scope of a “test and set”
instruction.
• A Computing System is a collection of processing systems wholly or
partially under the same management domain.
– The concept of “my computer” or a computing domain
• The Operating System then is really only the kernel
• What has been traditionally called the OS is necessarily a distributed
management system, you wouldn’t know it by what is said.
• Above that may be complex applications that manage their own
resources, i.e. with their own OS.

35. The Pouzin Society
© John Day, 2013
All Rights Reserved
35
Recursive Operating Systems
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Device Driver
Device Driver
Device Driver
Supervisor
Shell
User Process
User Process
Kernel
Sched
Mem
IPC
Sched
Mem
IPC
Sched
Mem
IPC
Each Process has an OS at its core to manage the “Tasks” of that process.
However, “Tasks” are processes to their “tasks” and so on. “Tasks” may be
allocated to their own processor.

36. The Pouzin Society
© John Day, 2013
All Rights Reserved
36
Gee, that is nice, BUT. . .
• We are solving Networking problems!
• Stay focused. One thing at a time!
• Except that the problem keeps dragging us into answering what is a
distributed application?
• Well, okay! . . . Then lets just use what we have . . .

37. The Pouzin Society
© John Day, 2013
All Rights Reserved
37
This Has Implications for DAFs
• If a DIF is a set of IPC Processes,
– really Distributed IPC Processes (DIPs?)
• Then a DAF must be a set of Distributed Application
Processes
– What else but, DAPs!
• What Does a DAP look like?

38. The Pouzin Society
© John Day, 2013
All Rights Reserved
38
Structure of DAP
• Local Resource Management is the basic Process structure.
– Have to manage local resources.
• Then a task for each of these to coordinate with other DAPs in the DAF.
Sched
Mem
Mgt
IPC
Local Resource
Management
Tasks
IPCManagement
RIBDaemon
ResourceAllocation
DAFManagment
Distributed Resource
Management

39. The Pouzin Society
© John Day, 2013
All Rights Reserved
39
What Do They Do?
• DAF Management - is the local agent for the overall management of
the DAF.
• Resource Allocation - corresponds to task scheduling and manages the
distributed aspects of the load generated by the tasks.
• RIB Daemon - ensures that the information necessary for the DAP to
perform its function is available, both for tasks and the DAF
components.
• IPC Management - manages the DAP’s use of supporting DIFs.

40. The Pouzin Society
© John Day, 2013
All Rights Reserved
40
Distributed Application Facility (DAF)
• A DAF consists of cooperating DAPs. Each one has.
• The Basic Infrastructure:
– Resource Management - Cooperates with its peers to manage load, generate forwarding table, etc.
– RIB Daemon - ensures that information for tasks is available on whatever period or event require, a
schema pager.
– IPC Management - manages the supporting DIFs, multiplexing and SDU Protection.
– Tasks - the real work specific to why the DAF exists.
• DAPs might be assigned synonyms with scope within the DAF and structured to
facilitate use within the DAF.
• Therefore, a DIF is . . . .
DAF Management
IPC Management Common Application
Protocol
Resource Allocation
RIB Daemon
IRM
IDD
Tasks

41. The Pouzin Society
© John Day, 2013
All Rights Reserved
41
Distributed IPC Facility (DIF)
• A DAF consists of cooperating DAPs. Each one has.
• The Basic Infrastructure:
– Resource Management - Cooperates with its peers to manage load.
– RIB Daemon - ensures that information for tasks is available on whatever period or event
the tasks (and the DAF components) required, routing update, other event notifications
– IPC Management - manages the supporting DIFs, multiplexing and SDU Protection.
– Tasks - Flow Allocator, EFCP, and relaying.
• IPC Processes are assigned synonyms with scope within the DIF and structured to
facilitate routing.
DIF Management
IPC Management Common Application
Protocol
Resource Allocation
RIB Daemon
IRM
IDD
RMT
EFCP
Flow Allocator

42. The Pouzin Society
© John Day, 2013
All Rights Reserved
42
A Single Unified Model that Encompasses Operating
Systems, Distributed Applications and Networking
Printer
USB-
DIF
WiFi-
DIF
OS - DAF
DiskLaptop
Operating Systems
IRM
IDD
DAPs
IRM
IDD
DIFs
Task
sched
Mem
Mngt
IPC
Tasks
Application Process

43. The Pouzin Society
© John Day, 2013
All Rights Reserved
43
• Part 1: Basic Concepts of Distributed Systems
• Part 2: Distributed Applications
– Chapter 1: Basic Concepts of Distributed Applications
– Chapter 2: Introduction to Distributed Management Systems
• Part 3: Distributed InterProcess Communication
– Chapter 1: Fundamental Structure
– Chapter 2: DIF Operations
• New Chapters and Extensions are expected as we learn more.
The Organization of
The RINA Reference Model

44. The Pouzin Society
© John Day, 2013
All Rights Reserved
44
44
What a Layer Looks Like
• Processing at 3 timescales, decoupled by either a State Vector or a Resource
Information Base
– IPC Transfer actually moves the data ( ≈ IP + UDP)
– IPC Control (optional) for retransmission (ack) and flow control, etc.
– IPC Layer Management for routing, resource allocation, locating applications, access
control, monitoring lower layer, etc.
• Remember that within a scope if there is a partitioning of functions, it will be
orthogonal? Well, here it is.
IPC
Transfer
IPC
Control
IPC Management
Delimiting
Transfer
Relaying/ Muxing
PDU Protection Common Application
Protocol
Applications, e.g., routing,
resource allocation,
access control, etc.
Application-entities
Application Process

45. The Pouzin Society
© John Day, 2013
All Rights Reserved
45
What are the Protocols?
• Only two
– A data transfer protocol, EFCP, based on delta-t with mechanism and
policy separated. This provides both unreliable and reliable flows.
– The common application protocol based on CDAP.
IPC Management CDAP
Resource Allocation
RIB Daemon
IRM
IDD
RMT
EFCP
Flow Allocator

46. The Pouzin Society
© John Day, 2013
All Rights Reserved
46
Error and Flow Control Protocol
(EFCP)
• There is one DTP (and possibly one DTCP) per flow
• One Relaying and Multiplexing Task per IPC Process
• At most, one SDU Protection per (N-1)-flow.
• DTP is a bit like IP/UDP (if you don’t look too close)
DTP- Sequencing, PDU
Identification, Fragmentation/
Reassembly, Data Transfer
Delimiting
Relaying and Multiplexing Task
SDU Protection
State Vector
DTCP - Retransmission
and Flow Control

47. The Pouzin Society
© John Day, 2013
All Rights Reserved
47
Common Distributed Application Protocol
• Common Application Connection Establishment (CACE) is the common procedure for
establishing application connections. It ensures that there is a known first exchange.
– Based on the OSI ACSE which was defined to be used recursively and has hooks for. . .
• An authentication module, which is a policy of whatever strength required.
• CACE and an authentication module can be wrapped around any existing application
protocol, e.g. HTTP.
• CDAP provides the minimal six operations and a basic object-oriented functionality
scope and filter.
– Would other programming paradigms lead to different functions?
CACE
Authentication
CDAP

48. The Pouzin Society
© John Day, 2013
All Rights Reserved
48
Only Three Kinds of Systems
• Middleboxes? We don’t need no stinking middleboxes!
• NATs: either no where or everywhere,
• NATs only break broken architectures
• The Architecture may have more layers, but no box need
have more than the usual complement.
– Hosts may have more layers, depending on what they do.
Hosts
Interior
Routers
Border
Routers

49. The Pouzin Society
© John Day, 2013
All Rights Reserved
49
Hosts Might Have More DIFs
“Link”{ Layers
Local App
Traditional Network
Transport Layers
Mail Appl
Simple App
VPN
Transaction
Processing
Application
(over a VPN)
Note that the VPN could occur one
layer lower as well or even lower,
but then it would just be a PN.
User Applications use whatever layer has sufficient
scope to communicate with their apposite.

50. The Pouzin Society
© John Day, 2013
All Rights Reserved
50
All Communication goes through Three Phases
• Enrollment
– Operations to create sufficient state within the network to allow an instance
of communication to be created.
• Allocation (also known as Establishment)
– Operations required to allocate an instance of communication creating
sufficient shared state among instances to support the functions of the data
transfer phase.
• Data Transfer
– Operations to provide the actual transfer of data and functions which
support it.
• Most of our attention has been on the last two. The first has often been ignored
and is usually seen as necessarily ad-hoc. But enrollment turns out to be key.

51. The Pouzin Society
© John Day, 2013
All Rights Reserved
51
How Does It Work?
Enrollment or Joining a Layer
• Nothing more than Applications establishing communication (for
management)
– Authenticating that A is a valid member of the (N)-DIF
– Initializing it with the current information on the DIF
– Assigning it a synonym to facilitate finding IPC Processes in the DIF, i.e. an address
(N-1)-DIF
(N)-DIF
A

52. The Pouzin Society
© John Day, 2013
All Rights Reserved
52
How Does It Work?
Establishing Communication
• Simple: do what IPC tells us to do.
– A asks IPC to allocate comm resources to B
– Determine that B is not local to A use search rules to find B
– Keep looking until we find an entry for it.
– Then go see if it is really there and whether we have access.
– Then tell A the result.
• This has multiple advantages.
– We know it is really there.
– We can enforce access control
– We can return B’s policy and port-id choices
– If B’s has moved, we find out and keep searching
A
B
Ahh, here it is!

53. The Pouzin Society
© John Day, 2013
All Rights Reserved
53
“Internet” Congestion Control
• Congestion Control has been a known issue since 1972.
– Except in the Internet who only discovered it when it crashed around their ears in 86
• The effectiveness of any congestion control is directly related to the
time to effect a change.
– The longer it takes the less effective the congestion control
• End-to-end implicit notification is predatory.
– Longest response time. Will work against any attempt to do it at a lower level with
shorter scope and better response time.
• The Internet has network congestion control,
– not internet congestion control

54. The Pouzin Society
© John Day, 2013
All Rights Reserved
54
What is the Difference Between
Flow Control and Congestion Control?
Data
Control
Control
Data
Data
Notify
Flow Control is a feedback mechanism co-located
with the resource being controlled.
Congestion Control is a feedback mechanism not
co-located with the resource being controlled.

55. The Pouzin Society
© John Day, 2013
All Rights Reserved
55
How Does It Work?
“Congestion Control”
• Congestion Control in TCP was always known to be a stop-gap.
• A DIF always has the potential for the full capability of functions.
• Do flow control (without retransmissions) between intermediate points.
– Better congestion control, really flow control
– Allocate different resources to different e-malls.
– Allows provider much more effective management of resources.
– Provides means to throttle flows being used for denial of service attacks
– All of these places? Doubtful. Research topic..

56. The Pouzin Society
© John Day, 2013
All Rights Reserved
56
How Does It Work?
The Internet and ISPs
• ISPs have as many layers as they need to best manage their resources.
Backbone
Regionals
Metros

57. The Pouzin Society
© John Day, 2013
All Rights Reserved
57
How Does It Work?
The Internet and ISPs
• The Internet floats on top of ISPs, a “e-mall.”
– One in the seedy part of town, but an “e-mall”
– Not the only emall and not one you always have to be connected to.
Public Internet
ISP 1
ISP 2
ISP 3

58. The Pouzin Society
© John Day, 2013
All Rights Reserved
58
How Does It Work?
The Internet and ISPs
• But there does not need to be ONE e-mall.
– You mean!
• Yes, it is really an INTERnet!
Public Internet
ISP 1
ISP 2
ISP 3
Internet Rodeo Drive
Utility SCADA
My Net
Facebook Boutique
Internet Mall of America

59. The Pouzin Society
© John Day, 2013
All Rights Reserved
59
How Does It Work?
The User’s Perspective
In this case, one host on the local network chooses to join
one of the available e-malls.
e-common DIFs
Provider Network
Local Customer
Network
Peering DIF
A Customer Network has a border router that makes several
e-malls available. A choice can be made whether the entire
local network joins, a single host or a single application.
e-common DIFs
Provider Network
Local Customer
Network
Peering DIF

60. The Pouzin Society
© John Day, 2013
All Rights Reserved
60
How Does It Work?
Security
• Security by isolation, (not obscurity)
• Hosts can not address any element of the ISP.
• No user hacker can compromise ISP assets.
• Unless ISP is physically compromised.
ISP
Hosts and ISPs do not share DIFS.
(ISP may have more layers

61. The Pouzin Society
© John Day, 2013
All Rights Reserved
61
How Does It Work?
Security
• The DIF is a securable container. DIF is secured not each component separately.
• Application only knows Destination Application name and its local port.
• The layer ensures that Source has access to the Destination
– Application must ensure Destination is who it purports to be.
• All members of the layer are authenticated within policy.
• Minimal trust: Only that the lower layer will deliver something to someone.
• PDU Protection can provide protection from eavesdropping, etc.
– Complete architecture does not require a security connection, a la IPsec.
Port:=Allocate(Dest-Appl, params)
Access Control
Exercised

62. The Pouzin Society
© John Day, 2013
All Rights Reserved
62
How Does It Work?
Security
• A Hacker in the Public Internet cannot connect to an Application in another
DIF without either joining the DIF, or creating a new DIF spanning both.
Either requires authentication and access control.
– Non-IPC applications that can access two DIFs are a potential security problem.
Public Internet
ISP 1
ISP 2
ISP 3
Internet Rodeo Drive
Utility SCADA
My Net
Facebook Boutique
Internet Mall of America

63. The Pouzin Society
© John Day, 2013
All Rights Reserved
63
There’s More to Come
• Next Naming and Addressing
– It turns out to be quite straightforward and simple.
• Then a Look at the Internal Operation of a DIF and the
Implementations.
• A Claim: One will not find a structure that is both as rich and as
simple as this that is not equivalent to it. Prove me wrong! ;-)
• But for Now. . .

64. The Pouzin Society
© John Day, 2013
All Rights Reserved
64
Questions?