Pop goes the cell

Not being a biology student, I've always only wondered what 'death' was, among other biologyie things. When I was younger, some films show some kind of white plasma flying towards the sky, leaving the lifeless body to symbolize death. The Max Excel fellow also believes in some gas called "praana-vaayu" (which he denied was oxygen) that keeps a man alive and is lost when he is dead. How this gas decides when the cells are appropriately damaged to depart, I never gotten round to ask. I must've also asked how they explained away organ-death, or, more fundamentally, cell-death. These deaths don't require the individual as a whole to die. Or, more interestingly, how do they fit in organ-transplantation which works because an organ doesn't die, while the individual dies. They probably would've come up with a multi-celled soul perhaps. But AFAIK, almost all religious people believe some kind of soul/plasma as the 'essence' of life. And that's the religious description of death, while what I am interested is in the scientific one.

So, when is a person dead?
Death, atleast biologically speaking, is a process rather than an event. But it's this irreversiblity (point-of-no-return) which is commonly referred to when one speaks of death. This point keeps getting closer to total death as technology progresses and our biological knowledge grows. This has led to many trials as to when a person is dead, legally. Of course, when you see someone with their entrails and grey matter spilling out onto the pavement, or decapitaed, or incinerated, they are properly dead. What we are interested, rather, is in determining this rubicon. Like someone said,
"Death is certain, since it is inevitable, but also uncertain, since its diagnosis is sometimes fallible"
(Note that I am not interested in the religious or legal death of a person, but the medical death.)

Is he dead when his lungs stop breathing? No. Mouth-to-mouth resuscitation can sometimes start the process. And iron-lungs can replace its work. Infact, a person may stop breathing for a few seconds several times during sleep. The extreme case, called sleep apnea, can be fatal.
Is he dead when his heart stops beating? No, not always. Remember "stand clear!" when someone uses the defibrillator and CPR in med-fictions? IOW, heart can be rebooted and even kept running afterwards with a pacemaker. Artificial hearts can also completely replace the heart.
Is he dead when both his lungs AND heart decide to stop? No, since the brain may be living and the body can be kept living in a life-support system for as long as anyone pays for it. Of course, if the episode was caused by brain death, then this argument is moot.
Is he dead when his cerebral cortex is dead? Not necessarily, but the individual as we know him is dead, because the cerebral cortex is the seat of thinking, personality, memory and the like. But we still have a living human being. Even sleep and coma can make this part of the brain appear dormant, though it's not the same as being dead and can be distinguished using an EEG.
Is he dead when his brain stem is dead? Yes (finally!). When this part is dead, the whole of the brain is dead. Note that, his other cells may still be alive. But even here, the cessation of brain activity must be for a period of time for it to be certain. When this death is not used as the ultimate indicator of death, you see people who decide to "rise from the grave" or "doing a jesus". Infact, beheaded chickens and other fowls may sometimes cluck around forever (if fed properly intravenously) as if nothing has happenned, because their brain stems are located a bit below the head. But of course, they lose their chickenness and survive on reflex alone. This suggests that there are two degrees of "alivedness" to a "brained" organism: one of the memory, and the other of the fundamental control functions.


Since B-grade movies has taught us that people can be killed in more than one way, I think it would be safe to assume that animal death can fundamentally be defined to be the death of whole of its brain. The cascade of cell deaths that preceded brain death and the cascade of cell death that follows brain death are not counted as death. The actual sequence of events that makes a person dead (of natural causes, of course) is a bit too biochemical for me to follow.

Then there's another debated topic of "natural death". What exactly causes "natural expiration"? I read what telomerase is and how it's repeated shortenening when cloning/cell-division can put a limit to the count of an individual's life. But apparently it's not the only answer. But I am sticking to the life-support functions (heart, lungs, etc) stopping to enrich the brain with food.

While going bored over searching for natural death, I came across a type of Cell Death called 'Apoptosis', from which the topic for this post is derived (Apoptosis. Get it?).

Cell death:
From what I gather, there are two ways a cell may die: Necrosis, where the cell may die of starvation, physical damage, chemical poisoning, etc, and PCD, where the cell suicides if it feels 'unwanted" (cell depression?). Apoptosis is one of the main type of PCD.

A cell becomes "unwanted" when new cells are ready to take it's place, or if it becomes damaged beyond repair by toxins or pathogens, or if it's apoptosis code in it's DNA is triggered by damage, virii, xrays, etc. And, as the name implies, each cell is embedded with the suicide sequence which can be initiated by one of the contributing factors mentioned above.

Contrary to what I thought, apoptosis occurs normally quite abundantly in a normal human adult. Homeostasis, a greek for the balance between old cells and newly produced cells, is an active balance that needs apoptosis to work. Infact, over 50 to 70 billion cells are produced each day and the same amount of cell has to die each day to compensate. If not, a cancerous tumour results. OTOH, if more cells die, I don't have a greek word for it, but it is obviously something bad. Infact, one of the ways in which HIV succeeds is by apoptosis of immuno cells. With so many cells getting replaced, the human body rotates an equivalent of it's own body weight in one year, it seems. Apart from homeostasis, the other important function of apoptosis is in differentiation of individual fingers in a developing foetus. Apoptosis is your friend. [link]


Whence such a morbid topic? I was going through the straightdope archives and found an article on being scared to death. Quite a few persons have been scared to death or willed to death. This got me scrambling for the basics on death. But the article itself provides most of the answers, which I noted only a bit later in my this research. Searching a bit late, I found this very interesting biology class discussion on death. Reading it makes me wish I had put more effort in securing an MS admission in an US university. Oh well, I have but little chance now.

XCIDR 2

This is basically a revision of XCIDR which I elaborated in my previous post. To reiterate, XCIDR is my uncertain brainstorm which aims to increase the IPv4 address space without resorting to IPv6 or it's required 'flag day' shifting of current IPv4 devices/applications.

To quickly recap, XCIDR relied on my observation of the first two bits of the subnet mask being unused. These two bits are encoded with IP address information to increment the address space by two or four depending on whether one of the bits is to be used as a subnet mask bit for the other one.

There's one more thing about the IP v4 subnet mask field: unlike the BCD encoding as in the address part, the subnet mask bits are pure binary (or whatever it is called). That is, to represent a number, say 13, in BCD you write it as '1101', while in pure binary it is writen as '1111111111111', or thirteen ones.

How did this come about, and why is it still being used? For this, we need to remember that the subnet mask is only the number of contiguous 1s to be ANDed with IP address for finding the longest-prefix-match. Sometimes ago when CIDR was just on the brains of it's creator, non-contiguous bit-masks were used as subnet masks. This scheme can split the network at more than one place. This requires a bit-mask instead of the BCD encoding.

But why non-contiguous subnet masks were introduced, nobody knew. But it was causing a lot of 'splitting'-headaches among the network admins. So it was advised against, but not made illegal, since it is perfectly compliant with the subnetting scheme. Which, in-turn meant that the 32 bit bitmask format stays. Later on, it was so hard, and hence unpopular, to have a non-contiguous subnetted network that routers stopped supporting it. Now, with CIDR and it's slash-notation, non-contiguous subnet masks are just plain illegal [link].

Which, as you might surmise, draws a case against the 32 bit subnet bitmask in present machines, and toward a 5-bit BCD encoded subnet mask. IPv6 makes this the standard. But IPv4 doesn't, as it would break all the current routers. True, but following the spirit of XCIDR, we might change the router and end-node logic without changing the IP, IGP/BGP/etc packet structure to acheive an increase in the size of IPv4 address space. I call this version of XCIDR as XCIDR2. It aims to increase the IPv4 address space from 2³² to 2⁵⁸ !

Here's how:
A subnet mask has 32 bits. Only the count of the number of 1s is needed off the subnet bitmask. The maximum number of 1s that can be in a 32bit field is 32. Representing it in BCD will require log₂32, or 5 bits. Now we are free to do anything with the remaining 32-5 = 27 bits.

If we are to allot some of the 27 bits to the IP address bits, then we need to allot extra subnet bits to the subnet mask to act as subnet mask bits for the new address bits. How to split the subnet mask bits now? With 5 bits the subnet mask can be used with a 32bit address field. Increasing the bit count by one will make the subnet mask 6 bits long. A 6 bit subnet mask in BCD can represent 2⁶=64 contiguous 1s (ones). This is more than enough, for when you add the remaining bits (27-1=26 bits) to the IP address, you get 32+26 = 58 bits.

So, finally what we have is an Ipv4 scheme with a 58 bit IP address, which can support about 288,230,376,151,711,744 hosts (288 quintillion). It's not much compared to an IPv6 address space, but can take care of any address space shortage before the IPv6 flag day, which by the way is not expected before the year 2025.

[Just for the 'ooh' factor: Ipv6, with its 128 bits, has been described thusly: If the earth were made entirely out of 1 cubic millimeter grains of sand, then you could give a unique address to each grain in 300 million planets the size of the earth.]

As in XCIDR, the IP address field and subnet mask field remains the same. This means that packet structures and routing tables need not be modified. Only the packet handling logic needs to be changed, both in the router and the end-nodes. The exact changes to the logic will be as in my XCIDR blog post. The only place it deviates from the plan is at the router.

As in XCIDR, we have an issue which can have many solutions. Then, it was the choice of XX and XY implementation. Now, it is the issue of choosing the division of the 26 extra address bits. The problem is obvious and straightforward: 8 is not a divisor of 26. This means that the highest octet in the address will not have 8 bits in them when you split it into 8 bit portions. 2 bits remain (26/8 = 3.25). In other words, the address will look something like this:
11.1111 1111.1111 1111. 1111 1111.1111 1111.1111 1111.1111 1111....

This question arises only because we are accustomed to such addreses which was introduced in a classful addressing system. With CIDR and VLSM, it makes no sense. Right? But we still 've got the human factor: Dealing with arithmetic involving upto 255 (2⁸) is better than dealing with arithmetic involving numbers upto 67,108,864 (2²⁶). So, I am gonna go with a partitioned space rather than an unpartitioned 26 bits. But how many bit partition will be the optimal? '13/13', or '2/8/8/8', or maybe a '10/16' scheme? I'll leave that discussion for later. For now, '2/8/8/8' bit scheme seems good and standard to me.

A router, will have to store an address of the form 4.255.255.255.255.255.255.255 in order to address an XCIDR2 network. This can be accomplished by storing the bolded part, as explained, in the subnet mask bits. When the router encounters an IP packet addressed to such a host, it simply concatenates the 26bits from the subnet mask and the 32 bit IP address in memory and runs the longest-prefix algorithm of CIDR just like always.

To address the issue of carrying the extra 26 bits in a standard IPv4 packet, I'll stick to the trick used in XCIDR of using the Options field in the IP packet. The reserved option mode ('11') can be used for this purpose. The only precaution a end-node/router will have to take is to ensure that the router it is sending the packet needs to be XCIDR compliant.

For all it's promise, XCIDR and XCIDR2 are far from realization because of the same problems plaguing IPv6: Less demand and cost of migration. And of course, the fact that this is a 'hack' at best is enough to turn heads...in the opposite direction :) But I am still keeping my fingers crossed for a chance at an RFC.

XCIDR

The acronym 'XCIDR' is what I called one of my pet projects that I was toying with when I was at college. Though it has not a lot to do with CIDR, I called it "eXtending the CIDR" to catch the spirit of CIDR's effect on the IPv4 address space. XCIDR aims at irrupting the address space of IPv4. XCIDR aims to increase the IPv4 address space atleast by a factor of 2, and at the most by a factor of 4. It tries to accomplish this feat while not requiring as wide a change in the IP network as a migration into IPv6 would require.

Let me explain. An aspirant, aspiring to increase the IPv4 address space, can do so by following one/all of the following strategies:

->find a better encoding for the address bits to pack-in more information,
->create a better allocation model or a better hierarchy of nodes in a network to increase the mileage of the address bits,
->increase the number of bits allocated to the address field.

I have no idea on how to optimize the existing power-of-two binary encoding scheme to employ the first option. The second option is explored by CIDR. The last option is the easiest one, and is explored by IPv6, and by me in XCIDR.

Simply increasing the number of bits in address field would work, but, you may ask, "isn't there IPv6 already here for it?". And you'd be right (and wrong too. Wait for a future post on truths about IPv6). But I don't intend to replace IPv6. What I want to do with XCIDR is to give the ailing IPv4 address space a couple of life breaths before it eventually reaches the end of the line. The trick is to keep the existing network/connected peers working with little or no change to them. Most important of all, the IP packet structure and the routing table structure shouldn't change. But there will be a change in the logic of IP packet handling and router logic. The DNS fields needs to be changed too to accomodate another field.


The idea:

The ideas behind my idea can be summarized in the following points:

->The Subnet masks don’t follow a power of two notation like the IP address. Rather they are made of contiguous ones (or for the pessimistic, zeroes). In other words, you won't find an subnet mask like 192.255.255.255. Non-contiguous subnet mask bits are extinct (which is why IPv6's subnet mask storage is different).
->CIDR says that you can use /30 to /0 aggregation. However, the only "useful" highest aggregation I've seen is /4 (multicast addresses).
->For example, a /3 address represents addresses from 31/3 to 224/3
It is difficult in the least to find a router that connects to such a large and paricular portion of the IP address space. This is because the address space is split into blocks and is owned by a variety of organizations. But such aggregation is not impractical at all. An admin working for a very major ISP may find himself in some circumstance to require this.
->But with /2, the networks get so big and fragmented that it is inconceivable (for me) that those two bits ever get touched. And a /1 aggregation, in fact, represents more than half the Internet.

With those realizations (or, assumptions), I plan to build a case for the uselessness of the first two bits in the subnet mask. In XCIDR, I plan to encode the extra IP address information into those two bits (Check "Workings" for why). Now I can do two things with these two "redundant" bits in the subnet field. One is to use both of them as extra IP address bits thereby tripling the IPv4 address space. I call this the XX implementation. Or, use one bit in the address field and the other bit bit as a subnet mask bit for the other bit. Though this option makes the increase in IP address space only twice as it is now, it may allow admins later to address the current CIDR network and the XCIDR networks seperately. I call this the XY implementation. (The 'X' represents an address bit and the 'Y' represents a subnet mask bit.)

I myself am in favour of the XX one, but more thought is required to establish one of them as the right model, as, obviously, only one of them can be implemented.


Workings:

Let us split the discussion of the working into two parts: Router-level and End-to-End.

Router-level:
How do peer-to-router and router-to-router communication work in XCIDR? A router's routing table looks something like this:

An Example Routing table

- Destination IP -	- Destination subnet -	- Interface -
10.16.0.0	255.254.0.0	1
192.168.1.0	255.255.255.0	2

The above example table is partial, in that Metric, gateway, status and other fields are omitted, but is complete enough in essentials for basic routing decision-making. A router, upon receiving a packet, extracts the IP address from the packet (the encoding is dealt in the "End-toEnd" heading) and checks in the "Destination IP" for a full match. If no match is found, the "Destination subnet" and "Destination IP" field are ANDed to see if the resulting network address encompasses the extracted IP. If so, the packet is routed over the corresponding interface. This much happens with non-xcidr routers.

With XCIDR, the extracted IP address would be of the form "XX.10.16.1.1" or "X.10.16.1.1" depending on whether XX or XY scheme was selected. To match such an IP address, the router will have to look at the first two bits of the subnet mask as well. The first two bits are internally considered as part of the IP address (in case of XY, only the first bit is considered part of the address, while the next bit is considered part of the subnet mask for the first bit). So now, even though the address and subnet fields of the routing table remain the same size, the computed destination address is of the form "X.10.16.1.1", which can be compared bit-by-bit with the one in the IP packet.


End-to-End:
So how does the end node send the extra two bits without modifying the IP v4 packet's address field? IP packets have a field called "Options". It has a 2 bit ID which allows for a total of 4 unique options to be set, of which 3 are already reserved. Option "11", the last one, is free as far as I can research (google). Each Option field allows for a custom sized payload. The extra address bit(s) can be sent via this. Routers can check this field along with the IPv4 address field to get the full XCIDR address.
But currently, the Options field is not "respected" by most devices and some routers as well. This is one thing that will have to be mandated with XCIDR.

But how will the end system know of the extra IP address field in the address of a server, say google.com? DNS. DNSes supply end nodes with the IP address of 'well-known' servers on the Internet given their domain name. But changing the returned address' width may break the existing devices and applications that rely on the 32bit DNS. How do you solve this? The only way I can think of is to return an additional field for the two (or one) extra address bit(s). I haven't studied the DNS packet structure closely enough, as of now, to conclude on a method.

If you have followed through the above points, then you would've noticed that hosts/routers/devices that are oblivious to the ways of XCIDR will not be able to address the "extra address space inhabitants". There has to be a mechanism for an end node or a router to know whether the destination end-node/router is XCIDR-capable. That mechanism may be as developed seperately. For example, an end node/router may check a router's XCIDR capablity by checking whether the router can recognize the Option field '11'. In the same manner, a DNS server may check an end node's XCIDR capablity by observing whether it recognizes and responds affirmatively to a DNS record with the extra address field.

In the end, what I've presented is just a short glimpse of a very long heart-throb of mine. It sometimes feels completely idiotic to even type this idea out, but sometimes it feels like I deserve an RFC for this :) I wanted to present a paper at the very least on my this idea, so many times. And every time I would scrap it. But now I am happy to have finally put it all down into words.