I currently think that it is important to have global conventions for building circuits thru the network, even if not all nodes deal with circuits. Earlier I thought of circuits as a local option that used channel numbers on links. Circuits were the only Tymnet routing strategy, aside from an internal routing mechanism to build circuits. Cisco’s tag switching technology tempted me to think of circuits as a local convention. In the original paper we proposed this function as a required part of DSR.

I have gone back and forth on whether DSR should support circuits as in Tymnet and Cisco portions of Internet. I now think that efficient use of the real hardware—nodes and links—requires flow control for important classes of traffic. Yes I am aware that Internet does not exactly provide that; I stand my ground. (I think that Internet does some things not described in any RFCs to accommodate big flows.) It may be useful to produce DSR nodes incapable of circuits, but I want an early circuit design which would be necessarily a global DSR standard. Pro global circuits.

Channel Numbers on Links and Circuits

This note describes a strategy where nodes take the initiative to convert some large data flows into a local circuit which I think is the Cisco strategy. I currently think, however, that this decision is best left to the agent with the most to gain—the router of the total flow. Those ideas are pursued in detail here. MLPS too.

Circuits help avoid:

traffic costs
where a down stream node is able to advise upstream node(s) that packets on some particular channel would be discarded just now,
delays
avoided by prompt notification to nodes that transmission may resume,
surprises
assuming the emergence of planning ahead for traffic and the emergence of bandwidth futures.

For a given link there will probably be an agreed upon fixed set of channel numbers available to be allocated to ‘circuits’. Both ends of the link know which numbers are already allocated and the complement set will be dynamically partitioned into two piles between the two ends for new allocations. Each end is free to allocate channel numbers from among its own pile of unallocated numbers. This avoids allocation messages for the same channel number passing each other on the link. One link message is ‘I have more numbers than you so here are a few for you.’.

Clouds

There are some problems above. I have described one way channels whereas most Internet flows are two way and most of those are mostly one way. In Tymnet the same channel number on a link was used for flows in both directions for some circuit; circuits were all two way. Alternatively channel numbers could be assigned independently on a link in each direction.

A related problem is the nature of the backpressure signal. If circuits are all two way then backpressure signals can be guided just as data is. While data in circuits is queued and delivered all in the same order as it is launched into the net, backpressure signals must be able to jump ahead of data and not be delayed by queued data in the opposite direction in the same circuit. Without such a protocol gridlock is possible in a single circuit. One backpressure scheme can be described as invitations which are link messages which say in effect “I have room to buffer k characters on this circuit.”. A more sophistical message is “I have room to buffer k total characters for any of these circuits.”. The latter protocol avoids classes of over allocation dilemmas. I currently favor these ideas.