Defects : Can they be avoided?

If you happen to be working in the IT industry, I can bet that you would have come across the word 'Defect' (or other popularly used word 'Bug') almost on daily basis. A 'defect' is nothing but a case of something not working as expected.

You can see defects usually in all walks of life. There are defects in the house you live, bus you take, car you drive, laptop you use. You would have seen various manufacturers recalling their products because they want to fix a defect.

Why one should worry about defects? Because defects are usually costly. Each defect has a cost associated to it. Cost of each defect depends upon which phase it got introduced and which phase it got caught. A defect that was introduced in design phase and caught in deployment phase will be the most costly defect. In the worst case, a defect could be life threatening. For example, a small defect brought down the space shuttle Columbia where all the astronauts were killed.

The big question is why and how defects get introduced?

In any product development, there are various stages. Let us take an example of software product as I am more familiar with this. We can divide the software product development in various stages like requirement collection, high level design, low level design, user-interface design, implementation, testing, deployment etc.. Defects get introduced in almost every stage.

Someone may ask, how come defects gets introduced in the testing phase. Actually testing is suppose to figure out all defects but as we know by experience that it is not the case. So this means that there is some defect in our testing because of which we are not able to detect all defects.

When you designs your product, it is almost impossible to test the design for all possible inputs. So there will always be some inputs for which you cannot test your design or implementation. So theoretically, there is a possibility that your design may fail for some such input. If I extend the above, we can safely say that in theory, it is almost impossible to avoid defects. Similarly, a developer without required level of skills, implementing the desgin will introduce more defects.

In my opinion, as mentioned above, in a completely new software, defects are introduced in all the stages. Once defects are seen, they are fixed. This is when more defects are introduced in the software. So this becomes a unavoidable cycle.

Why defects are introduced when fixing a defect? There could be various reasons like the developer does not know the big picture or there is not enough documentation about the implementation or there is no review process or the developer's skills are not good enough. In my opinion, review process can help in most of these cases. For example: even if the developer fixing the defect does not know the big picture, the chances of getting defects can be reduced if an expert review the fix. In one of my earlier post, I had talked about the necessity of code review. In that post, I argued in favour of code review which helps in reducing the defects in the system.

So defects are costly and seems unavoidable but there are means and processes with which we can reduce the occurrence of defects. I am a big supporter of review process. In my opinion, number of defects in the system can be reduced if there are reviews in each stage of development. Also, I think there must be more focus on better reviews in the preliminary stages like design. What do you think about this? It would be great if you can share the particular mean or process that has really helped you in reducing defects.

Multicast in Ethernet LANs

Now that we know why do we need multicast and how multicast addressing works, let us look at how Multicast works in Ethernet LANs.

As described in my earlier post on multicast addressing, Applications/Servers use a Multicast Address (Class D address) while sending out the contents. This multicast address is used as the destination address in the IP data packet.

Please take a look at figure 1, what do you think who all will receive the multicast traffic sent by the sender?

Did you say 'all-of-them'? If yes, you got it wrong. To tell you the truth, none of them will receive the multicast traffic as they did not indicated their interest beforehand.

So how do the receivers indicate their interest? They use a simple protocol known as IGMP (Internet Group Management Protocol). I will talk about how IGMP works in detail in a future post.  For the time being, just remember that a receiver uses IGMP membership report messages to indicate his interest in receiving multicast traffic for a specific Group Address.

Now look at figures 2 and tell me who all will receive the multicast traffic sent by the sender?

Did you say R1 and R2? If yes, you got it right. Congratulations!

With the figures, can you figure out what difference does the IGMP membership report messages made in this network so that R1 and R2 can now receive the multicast traffic? Actually speaking, nothing, IGMP messages do not change anything. So then question is, how does R1 and R2 can now receive multicast traffic by just sending IGMP messages? Answer lies in what Hosts does when they send IGMP messages?

I am sure most of you already know, how a hosts accept traffic for himself on a LAN. But let me explain it in my terms. Hosts uses Ethernet NICs to send/receive traffic in LANs. Every NIC card is configured with a unique 48 bits MAC address. When one hosts (or any network element) communicate with other hosts, it figure out the destination host's MAC address using ARP. It then prepare an Ethernet Packet with that MAC address as destination MAC and sends the packet on LAN. All Hosts NIC card receive this packet and compare the MAC address with their own MAC address and only that hosts whose MAC address matches, accept the packet. Look at figure - 3. Destination MAC in ethernet frame is of R1 so only R1 accept the packet.

Now there are two things that comes out of this. One is that what MAC address should the sender use when sender is sending a Multicast packet. Another is what should the receivers do to accept the multicast packet?

To keep things simple, an IP multicast address is mapped to an Ethernet MAC address. Here is how the mapping works. Out of 48 bits, first 25 bits are a constant (01 00 5E 0) while rest of the 23 bits are same as the lower 23 bits of the multicast IP address. For example: 224.1.1.1 will map to 01 00 5E 01 01 01.

Do you see a potential issue with this mapping? If you do, take a pat on the back. With this mapping scheme, two different Multicast IP address can map to the same MAC address. If you try to map IP address 224.1.1.1 and 235.1.1.1, they both will map to the same MAC address 01 00 5E 01 01 01. This happens because out of 28 unique bits of multicast address, only 23 bits are used in mapping. Take a look at figure - 4 to see how the mapping works.

Your next question might be that why we ended up with such a scheme. Why did not someone got it right? Actually there is a small story behind this. Steve Deering requested a block of MAC address to be reserved for IP multicast use such that he could create a unique MAC address for each multicast address. But he was allocated a smaller block which had  first 25 bits fixed and we ended up with this scheme.

Now that we know how a multicast address is mapped to Ethernet MAC address, let us see how the multicast communication works. When a receiver indicates its interest in receiving multicast traffic for a given group, apart from sending an IGMP membership report, receiver configure their NIC cards with multicast MAC address calculated based on the mapping of the multicast group address. It means if receivers is interested in multicast group address 224.1.1.1, it configures the NIC card to receive traffic with 01 00 5E 01 01 01. Because of this, any data traffic received with this multicast MAC address is accepted by the receiver. Similarly a sender populates the destination MAC address by calculate the multicast MAC address based on the mapping of the multicast group address. Please look at figure - 5 to understand what I am suggesting.


This is the first post where I have tried to add as many figures as possible. Please do let me know how you like this post in comparison to others where I avoided figures completely. I will leave you with a question now. If multiple multicast group address can map to single MAC address, how does the end hosts filter out packets he is not interested in?

How IETF works?

I illustrated India's contribution in IETF in my earlier 'India in IETF' post and ask you to provide comments and suggestions on how we can improve the quality and quantity of India's contribution in IETF.

In the past, during various informal discussions, people mentioned that they are not aware of how IETF works. I always pointed them to relevant links but I am sure not many have read through them. So I decided to give a brief run down on how IETF works in my own words. Please note that it is like a small crash course on this subject and if you want to get more information, please do go through the links posted at the end of this post.

IETF is a standard body that produces highly relevant technical documents which are used by people to design, develop, use and manage the Internet. IETF has organised its work in different Areas. At present, there are 8 active Areas in IETF. There are several Working Groups in each of these Areas. Each Working Group has a pre-defined charter that identifies the goals and milestones for the working group. There are currently more than 100 Working Groups in IETF. I will talk about the process of creating a Working Group in some future post.

Each Area is managed by one or more Area Directors (ADs) with the help of IESG (Internet Engineering Steering Group). IESG members are Area Directors who are selected by Nomination Committee. Each Working Group is managed by one or more Working Group Chair.

Most of the IETF work happens through mailing list. Each Working Group (WG) has its own mailing list. Anybody can subscribe to any Working Group's mailing lists for free and start contributing.

IETF produces RFCs (Request For Comments) which are implemented by various OEM vendors in their products to make Internet work. Authors write up a private draft which describe a specific problem and the proposed solution. Authors then submit their draft to the most relevant Working Group. Authors can post their draft to other relevant Working Groups as well. For example: A draft can be submitted to both PIM WG as well as L3VPN WG if the draft is related to both the Working Group. Working Group reviews all the proposals and accept those proposals on which Working Group like to work. These proposals are then submitted as IETF Internet Drafts. These drafts then go through extensive reviews in the Working Group. Once Working Group feels that a specific draft has gone through enough reviews, Working Group chair submit the draft to IESG. The draft goes through another review by IESG members and once it is approved by IESG, it is passed to RFC editor to convert it into a RFC.

The easiest way a person can contribute to a Working Group is by reviewing the various Internet Drafts submitted to that Working Group. Again, as mentioned above, its free. You just need to subscribe to the mailing list. This helps everybody as it enhances the quality of the drafts and in turn the output of IETF.

There are regular IETF face-to-face meetings which are organised three times a year. Two of these meetings usually happen in USA/Canada region while one meeting happens somewhere in rest-of-the-world. These meetings are as technical as you can think of. Each Working Group meets to discuss their on-going work. In these meetings, people discuss their current and future work, find co-authors, get feedback on their work and network with people.

For more information, please refer to the TAO and page setup for newcomers in IETF.

Multicast addressing : Whats the big deal?

In my previous, I tried to reason why IP multicast is required and how does it help in the network. In this post, I will focus on multicast addressing.

IP multicast uses Class D address space. First address is 224.0.0.0 and last address is 239.255.255.255. This range is also referred as 224/4.

Similar to unicast address space, some of the multicast address ranges are special. 224.0.0.0/24 are known as local multicast addresses. Packets destined to these addresses are not forwarded by a router and treated as broadcast packets by switches. Addresses in this range is used by various protocols like RIP, OSPF etc. to communicate with immediate neighbors. 232/8 are used only for Source Specific Multicast. I will talk about different types and how they are used in greater details in some future post.

IP multicast is built upon the assumption that senders and receivers do not need to know where the other is sitting in a network. They just need to know the multicast address that they need to use. Receivers shows its interest by sending out an IGMP/MLD join request with the multicast address they are interested in while senders just sends multicast data using the multicast address.

So how does an application finds out which IP multicast address to use? Very simple. Pick any multicast address and start sending data using that address. Am I kidding? No. This is how it is suppose to be.  But then how do receivers suppose to know which multicast address sender is using? Some out-of-band mechanism usually manual configuration.

But should not there be some means for sender to decide on a multicast address so that it is not in conflict with others. To start with, IP Multicast did not had any allocation mechanism. People came up with various mechanism to allocate multicast addresses like MALLOC but nothing was widely deployed. Later, some mechanisms like GLOP addressing, SSM address space, Administrative scope address range etc. were defined to help administrator with a range of multicast group address they can use within their network or globally. So usually sender is configured with a multicast address that it should use.

Now a days, Applications uses an address from administrative scoped address range if multicast traffic is not suppose to go out of its Autonomous System (AS). Application can use an address from the GLOP multicast address range or SSM address range as it will be unique globally. Receivers are told about this address through out-of-band mechanisms like passing it back in a http response.

If you want a consolidated information on Multicast address architecture, please read through RFC 6308. A whole list of the special multicast addresses can be found in Wikipedia. IANA maintains the IP multicast address space registry here.