To sum up to this point. As some of the more regular dopers may be aware, I am currently getting my Master’s in computer information systems. Everything is fine and dandy up to this point. However, this semester I am taking the network design and management class which makes no sense to me and has nothing to do with my career path. I have been fine up to this point because I have been able to figure out what I need to figure out to get B’s in this class.
Unfortunately, this latest homework assignment means nothing to me when I look at it. I don’t have a clue how to approach this, partially because this doesn’t come naturally to me and partially because the teacher thinks lectures need to be conducted at a rate only Speedy Gonzalez would comprehend.
I’m not looking for solutions here (because I find it hard to believe anyone would do this for kicks) but I am looking for a website or something that would help me figure out what the heck I am supposed to be doing.
The following link will open a PDF document. My homework
The text of the problem is pretty straightforward, assuming that you know what ATM is, and how data encapsulation works (in general) when you package payloads in different protocols. The specific questions:
Is there one of these questions that you don’t understand? I don’t know the term “TRIT.”
Basically, she’s wanting to demonstrate how efficient it is to transfer data over a scheme like this. Your multi-megabyte data package is chopped up into 9140-byte segments, and a 20-byte TCP header is added to each. Then each of those gets a 20-byte IP header. Then each of those is chopped up into 48-byte chunks, and to each 48-byte chunk, a 5-byte header is added (an ATM cell is 53 bytes - 5 header, 48 payload).
I would think that a person making a career in information systems would need to know this stuff.
Also, OC-3 is really 155 Mbit/sec, but she says it’s 150.3 Mbit/sec. I think she’s already accounting for the overhead of doing ATM over SONET, so she’s already solved a large portion of the problem right there!
Just so I wouldn’t feel completely useless, I looked up TRIT - “True Rate of Information Transfer”, I’ve never heard of it before. And I challenge anyone to find a definition of that term on-line. (Except for the jargon file definition “one base-3 digit, analogous to “bit” for one binary digit”.)
If I were to guess, it would mean the apparent byte rate of the connection as demonstrated by the file transfer (filesize divided by transfer time), but that is just a WAG.
But echoing CurtC, what you need to do is to look at what happens as the file transfer program hands data to the TCP layer, as the TCP layer hands segments to the IP layer and as the IP layer hands datagrams to the ATM layer.
If there’s an exam coming up on this course, I think you’d do well to spend a few hours getting the concept of the protocol stack and payload encapsulation straight, it’s very central to the subject.
My guess is that the TRIT would be the efficiency (found in step e) multiplied by the transfer speed (given as 150.3 Mbps). But that’s just a guess. The rest of the problem seems to be just an exercise in long division
A 3,007,000 data file is chopped into 328 and some change tcp segments (3007000/9140). Since it is 328 and change in reality there are 329 tcp segments (you cannot have a partial segment). Each tcp segment has a 20B header added. So each TCP segment is 9160B in size. The TCP segments are then changed into IP datagrams with a size of 9160B + 20B for the IP header. Then each datagram is divided into ATM Cells of 48B each + a 5B header. So, at the ATM level each segment is 192 cells (9180/48).
a) 329 unless I am reading this question incorrectly (File size/segment size)
b) 192
c) 192*329= 63168 (cells per datagram * number of datagrams)
d) 63168 * 53 = 3,347,904 (number of cells * bytes per cell)
e) 3007000 / 3347904 = 0.898173902238534916174418382366997 (see homework)
f) tired of this, ain’t gonna do it, never heard of TRIT
g) see f)
You really should check my math as I spent about 5 minutes on this and could be wrong.
As others have said you really need to understand this stuff. I don’t have a degree but I have worked in the area for years and it is important. If you are going to work in CIS-MIS-IT you need to understand networking very well. The way things are going every app is going to be networked.
I’m just a PC hobby geek but most of the IS-CIS-MIS types I’ve dealt with seemed to mainly focused on maintaining the security and reliability of hardware platforms and OS databases and bread and butter applications across networks with canned net admin and security tools. How is understanding the underpinnings of packet header math going to really matter to 95%+ of the IS managers out there in their day to day jobs"?
I’m not challenging your assertion, I’m just curious in that based on their description what they did it would not seem to be a really important part of their jobs.
As a side note, I would tend to not agree with needing to know this kind of stuff to have a career in the field. I work building databases and other than having the need for cursory knowledge in networking, i don’t really need to know how fast something can transfer over a twisted pair wire or what the link efficiency of something is.
Either that, or my teacher is so bad that he has kept me from realizing the potential of this knowledge due to us having no book and his manic speed teaching.
While there are undoubtedly DB engineers who have gainful careers without ever knowing anything about networks, chances are you’ll find yourself designing DBs with network performance as one of the constraints - WAN bandwidth is expensive.
If your application underperforms due to network problems, it might be to your advantage to have the basics in place. Otherwise, you’re completely at the mercy of ruthless networkers like me
Seriously, knowing the basics of other specialties makes it considerably easier for anyone to take part in (and eventually manage) bigger IT projects.
As Spiny Norman said the more everyone knows the better.
I worked at a very large ISP in the Network Operations Center(NOC). There were numerous times that the fix to a problem came from someone in a different area. IE, a DB person would figure out where or what was wrong with a *nix system or something similar.
At the same company I also helped to develop and impliment a training and troublshooting DB. I and some others did the testing and created the content. While doing this it became pretty clear that some people knew the network and some didn’t. The people who truely understood the network were the people I wanted to deal with. Getting the system up and running took some time but it was interesting. A few months later there was a reduction in force and almost everyone who hit my ‘just know their job but nothing else’ list was RIF’ed. I was just a worker bee and had no say in who got the axe but I found it interesting that the bosses basically agreed with my thoughts.
One last reason to take this stuff seriously - You never know what job you might be asked to take. At the last company I worked for they threw me so many curve balls it became routine. About once every two weeks they would come up with something for my team to handle, most of the time it was an area we knew little about. Being able to handle anything given to you is really valuable. In fact, my last employer offered to make a new position for me in a call center to keep me with the company. (I was hired in Albuquerque and they moved me to VA. I left VA to move to Vegas because I hated VA. They offered me my own job in ABQ)
