Here are answers to some questions for Assignment 2.
Note that the more recent answers are added at the
start .
- As a general comment, I do get a bit tired of referring
questioners back to material that is already in the handouts
....
Please read them, preferably before asking
questions.
- Several students use the term "octects", which should be
"octets".
This is a standard term, used many times in the
text and handouts and it is just carelessness to get it
wrong.
- Please try to put your questions in proper sentences.
Some questions here rambled on and on, with so many
ideas mixed together that it is hard to get the meaning.
For Q1 of A2, you define IPv6 has a 40 octet header, while
IPv4 has a 20 octet header. But from text book(p513-p515
2nd edition), I learn that IPv6 actually simplifies the
header comparing with IPv4. In other words, IPv6 actually
has a shorter header than IPv4. So I guess if we answer the
question(iii) of Q1 following your definations, we probably
will have some reverse idea with the text book. I guess
maybe I'm not understand your assignment question properly,
could you help me on this point, please? Thank you very
much!
You confuse "simpler" with "shorter". IPv4 has a 20-octet header with a
very complex structure, while IPv6 has a 40-octet header with fewer
fields, but most of them longer.
what do you mean by "assume that there is no copying for physical
transmission"? Does this mean we calculate the user data rate without
concerning about all copying cost? or we have to calculate two user data rates
here, one with all copying cost, the ohter with only TCP checksum?
Assume no copying at all, for this part of your answer.
do all memory copying happen on receiver side? I mean copy the Ethernet
frame into IP packet and copy IP packet into TCP segment before the receiver
gets the message.
Yes. Read the last line of case 2 of Q 2(iv).
About checksum. When receiver got a frame from sender, the thing needs to do
is recalculate the checksum and compare it with the checksum in the frame,
right? My question is, does receiver need to calculate the checksum again when
receiver send an acknowledge? I think it is yes, but the two checksum look like
same if the message is correct. It makes me confused.
The receiver does have to calculate a checksum for the acknowledgement.
But the acknowledgement message is quite different from the initial
user data. Usually it would be just the TCP header, with no data at all,
(as for Q 1) but for this assignment Q 2 I have said that it is the same
size as the user message.
About acknowledge. In Q1(ii) You said "Assume that each user message is sent
as a sequence of segments and packets, and that the sender then waits for an
acknowledgement before starting the next user message." Does this mean there is
only one acknowledgement for the whole transmission, not for every Ethernet
frame. I think yes. But if this is true, it looks very low efficiency for a
large message since if only one frame is wrong, and the acknowledge is
negative, then the sender has to send the whole user message again.
There is only one acknowledgement for the whole segment.
Wait until we do the TCP protocol properly.
just wondering that if the message is 2000bytes , do we need divide it into
two packets, like : 1000byte in one packet each , and the transmittion for
2000byte cost two times.
Yes
Hi,about the 2nd case of Q2's part(iv) ,I am not sure whether we should
consider the time costed when the PDUs at each level copied by protocol layers
from lower layers to reverse to SDUs at recipient end when it get message?
Include ALL the times. The acknowledgement cannot be generated until we
have done the checksum, and any copying to reassemble the fragments of
the original segment and user data
For question 1 of the assignment, do I need to calculate the LLC/SNAP header
(is it for both the Ethernet and the IEEE 802.3?), in your answer to the
question about LLS-SNAP header, I don't understand the number 0x600, is this a
hexidecimal number, and what is its value in decimal number, so the "data
length/type" field specifies a number which is the actual user data value
right, in the handout, it said that if the value is <1536 (is this the value of
the value of the actual user data?) then a special LLC/SNAP header is needed,
but we don't know the value for the LLC/SNAP header, and the value that is >
1536 a special header is needed too, but those refer to the older version of
IEEE 802.3, and Ethernet respectively, so do I need to concern about the
LLC/SNAP header for both of the questions?
0x600 is a haexadecimal number, equal to 1536 decimal. Using the older
terms, an LLC/SNAP header is used only for the IEEE802.3 format (with
the length or type field <= 1500 and giving a length). If the field >
0x600 (1538) and therefore interpreted as a type, no LLC/SNAP header is
needed.
For question 2, does the copying operation refer mean that when tcp converted
to ip packet this mean that the copying operation have to perform, and it
applies for very packets, frames, and LLC/SNAP header, the handout said that
copying tcp segment into ip packet may be done for every segment, but my
question is do we have to perform the copying operation for every segment and
frame, what is the reason for may not copying for every segment, is it because
of minimal overhead, and also I have another question, for part (i) about
simplifcation, are there more than one quantifier, and also can the
simplification be a little bit over 10% say within 10-11%, is this acceptable?
There are two cases of copying to consider.
One is that there is no copying at all and theat we have clever data
structures that let us pick out pieces of the user data or TCP header as
needed.
The other is that we copy within both the Transport (TCP) layer and the
Network (IP) layer, so that both layers copy at least all of the user
data.
also about case 2 of Q2's part(iv),we should consider the time for copying
TCP segment into IP packet,but,do we need care about the time costed by copying
TCP segment out from IP packet after recipient getting message? and, can we
assume that what happens to message will also exactly happen to acknowledgement?
Yes.
Just to clarify, for Q1 (ii), do we need to calculate the user data rate after
user messages of 500 and 10,000 been sent completely (thus only one data rate)
or do we calculate the user data rate for each user message.
Calculate for both (2 answers).
For QUESTION 1:
(ii) Is that each user message gets 1 TCP acknowledgement regardless of its
length?
Yes, and regardless of the number of IP packets that it is split into.
I was wondering if you could tell me what LLC & SNAP actually stands for and
what it means? And I was also wondering Does the data link layer place each IP
packet in an Ethernet frame?
LLC stands for "Logical Link Control", the upper half of the DataLink
layer in the 802.2 standard.
SNAP means "Sub Network Access Point".
I think both are in the lecture notes.
Could you please clarify part of the description in question 2 of the
assignment for me. The sentence is: "if the received segment is 1160 octets,
then the acknowledgement will also use a segment of 1160 octets." I this
suggesting that the "acknowledgement" is the process of verifying the checksum
on the received segment of 1160 octets, or does it mean that
the "acknowledgement" is a segment of 1160 octets sent in reply? If the
latter, I presume that the acknowledgement segment is all padding, and
therefore does it need to be copied into the TCP and Ethernet frame, or would
it be generated in hardware at no cost?
The acknowledgement to a message is within another message of the same
length, probably quite unrelated to the first one.
Usually we would
expect the acknowledgement to be an empty TCP segment (just the TCP
header, with no data), but for this assignment we specify a big
acknowledgement message.
Just to clarify, for Q1 (ii), do we need to calculate the user data rate after
user messages of 500 and 10,000 been sent completely (thus only one data rate)
or do we calculate the user data rate for each user message.
As earlier. Calculate for both (2 answers).
For case 1, how much copying is "minimal copying"? From what I can see, it
refers to copying from TCP segment into the IP packet, but I'm not sure if it
is a full copying (costing 200ns/4 bytes), or only a part copying which we can
assume to have no cost (as its eliminated by "clever data structure")?
Minimal copying implies as little as possible and therefore probably "no
copying", and therefore zero cost.
I'm a little confused about question 2(iv) case 2. Looking at the second
lecture notes slide 11, is the user information copied before the transport
header is added? or after the transport header is added?
It could be either, depending on the implementation.
The difference is probably small (refer to other parts of this assignment).
I just got a new question about the minimum frame length.
The handout said "the minium frame length is 64 octets(including header and
FCS, but excluding preamble)", but in the figure of Ethernet Frame Format, it
includs preamble and start of frame delimiter clearly. Why we ignore these 8
octets when we are talking about minium frame length? They are as important as
other parts of the Ethernet frame format. And you also point out "Allow for the
preamble and all other parts of the Ethernet frame".
That is what the standard says.
Do we need to think about how sender deals with the acknowledge? I mean
sender got the frame from receiver, and recover the acknowledge from it.
No. We are concerned only with the fact that an acknowledgement is generated,
transmitted and received. All that is important is the time that that takes.
When receiver is sending acknowledge, does it need to checksum, copy, etc? I
think the answer is yes, right? I just feel confusing about it since it looks
like a tedious loop!
Yes it does, and it is all very tedious and can take a long time.
Which is really the point of this question!
Q2(i) said "Apply these simplifications to the remaining answers. Can I just
answer this question, and do not simplify the calculations?
This is an instruction which says that the simplifications must be applied.
Do it!
In the assignment sheet,it says 'The TCP, IP and Ethernet layers form
a layered protocol stack, as discussed in lectures, with each adding a
header (and possibly trailer) as the message passes down from the user,
for transmission.'
I am wondering which lecture it is I can find the material about
this?
It's there in the second handout, and in various other places as well,
including the end of the Assignment.
For the Q1(i),do I need to add Ethernet overheads to each packet or
just add 20 octets for overall tcp segment and 40 octets for each IP
packets and ignore the ethernet overhead?
You must include ALL bytes and overheads that are transmitted on
Ethernet, including user traffic, headers and Ethernet framing.
To find out what is included in the Ethernet payload, look
at all the preceding encapsulation, headers, etc.
For question 1, do we need padding if a packet is 4 octets, but the
payload included both the tcp, and the ip header, which is 60 otects and
exceed the minimum requirements of 46 octects, I think we don't need
padding in that case, am I right?
Look at all of the information which is actually put into an Ethernet packet;
if that is less than 46 octets (NOT octects) you need padding.
For question 2 part (iii), do I need to calculate the checksum for
each user packets, and the copying operation, since it stated that there
is no memory bandwidth overhead, and can you explain what the checksum
is for, is it just for bandwidth overhead, or is it also for checking
each user packets, and how about the copying operation, do we copy each
segment before transmitting the segment, and likewise for the
acknowledgement packets, in the assignnmmebt handout, it stated that the
user message must be verified before acknowledged, does this mean
additional checksummed?
Q2 (iii) [as in the printed assignment] says "no memory bandwidth
overheads at all" which means no time for checksum calculation, copying
etc. Just count all the bytes that must be sent.
This gives an optimistic performance.
The checksum must be calculated before transmission and after reception
to check that the received message is correct. It is thus an overhead at
both ends, and for the acknowledgement as well.
For question 1, can you explain what the N mean in the frame format, does it
refers to the tcp header, ip header, and user data, or is it just the user
data, since I have included the tcp header, and the ip header in the calculation
(the tcp, and the ip header is not in the frame format)?
N means the total data carried by the Ethernet/802.3 frame and includes the
user data and all headers and trailers.
Can you please explained what you mean by "Assume here thta each tcp segment
(with its header) is first checksummed"?, and what is the user data is 1400
bytes for all the parts in question 2?
* One of the things done in building a TCP segment is to calculate its
checksum. The checksum calculation always occurs and cannot be avoided.
* The 1400 bytes of user data is whatever the user wants to send.
for the frame format IEEE 802.3(.....8*Nbit...32bit) where 46<=N
=<1500 is N in bytes or bits?So the maximum payload could be 12000bits
or 1500bytes ?
N is measured in bytes (more correctly octets). The maximum size of an
Ethernet payload is 1500 octets = 12000 bits.
Do we assume the size of "a single user segment" or "a single user
message" is 1400 byte?
The last line of the introduction to Q 2 says "1400 byte user message",
which is after all all that the user is interested in.
A "segment" is an internal construct of the communications system.
For question 2(i), what are the results refering to? Does it mean the
transmission speeds like we calculated in question 1 (eg. 100Mb/s etc)?
And if it is, what are simplification on? Because we read the book and we could
reduce transmission time if we use sliding windows. Is that what you're asking?
The results are whatever you are asked to calculate.
For example, if you find that you must divide a number by 1060, dividing by
1000 is much easier and gives an error of about 6%, which is within the
allowable difference. (Be careful though that you do not make such
simplifications in numbers that you then subtract, but this should not
apply here.)
In Assignment 2 Q2 (iv)2, which is the 2nd case of the questions... according
to what it is stated in the question, it requires 4 copying when we send a
message (2 from sender, 2 from receiver). But I was just wondering, do all
these copying apply to the acknowledgement as well? It's because I don't
really see the point of copying anything from the memory for the
acknowledgement. And even if the copying is required for the acknowledgement
part, what exactly is it copying from the memory?
It is reasonable to assume that the same situation applies for the reply.
The acknowledgement will be some other user message in the reverse direction,
possibly quite unrelated to this traffic, with the reply placed in its header.
I'm sure I've said it before, but if you are not certain
about something like this, make what seems to be a reasonable assumption and
write it down.
You will not be penalised if the assumption
is sensible.
(The following questions are not related to the assignment, so please reply)
On the 20th slide of the Errors and Compression notes- point 5 - where it
said "If the brust has length r+1, r(x) will be zero only if r(x) = g(x), and
with probably (1/2)^(r-1)", what is r(x) representing in here? and could you
please explain this point as well? (As i don't really quite understand what
does it mean)
I think you mean "probability" rather than "probably".
The words are closely related but have quite different meanings and must
NOT be confused.
This is an example of the problem that I see all
too often, that students "latch on" to a similar but wrong word and end in
all sorts of trouble.
r(x) is the remainder after division and is zero only if the
error polynomial is precisely, bit for bit, equal to the generator.
As g(x) has r bits, there is only 1 chance in 2r+1
that the two will be equal.
I am still trying to make sence of the wording of the question one.As far as i
can understand we have this: 20octets tcp header, 40octets IP header,message-
frame format(7octets preamble+1octtet start+ .... 4octet FCS).Am i on the right
track ?
Yes.
Q1 (iii) ......(IPv4 header = 20 octets)
But a table from the textbook p.538 (3rd edition)
shows that IPv4 header is 24 octets. (32bits*6).
What is happening?
The table includes options, which are variable length after the header and
might or might not be present between the header and the data.
The header itself is always 20 octets.
3. In part1 second question, after the sender gets acknowledgement
from receiver and sends the next message, does the sender sends the same
size message repeatly or he will send different size message?
Assume that the messages are all the same size, unless told otherwise
All user messages are 1400 bytes.
This Q&A is from the Q&A page.
On the assignment handout Q1-(2) you said "estimate the user data rate for user
messages of 500 and 10000 bytes"
Then what is the message of 1400 bytes?
Could you please describe the situation more precisely?
The 1400 is the size of ALL user messages in Question 2.
Question 1 used a range of different sizes.
Do not confuse the details of the two parts.
1) Question 2 part (i) - I have problems understanding what is
actually being asked in the question. "The results may differ by as
much as 10% from the correct values." What results/values/calculations
are you referring to?
The instruction at the end of part (i) says that these approximations
apply to all of the calculations and results from the rest of Question 2.
2) In Question 2 part (ii), is the 'user transfer rate' the same thing
as 'user data rate'?
Yes
3) In Question 2 part (iii), you said checksumming and copying is
done on both transmission reception. Since the receiver must send an
acknowledgement back to the sender and the sender must 'interpret' the
acknowledgement too, is there another round of checksumming and copying
done on both sides for the sending and receiving the acknowledgement (as
opposed to sending and receiving the user message)? i.e. for each
message, whether it's a user message or an acknowledgement, there is
checksumming and copying done on both sides?
Yes.
i am not sure the meaning of the Q2 part1,states that:
The results may differ by as much as 10% from the correct values. What
simplifications does this allow in thecalculates(or what quantities may be
omitted)?
do i just state that there may be some stage in memory bandwidth overhead or
transmission which may be omitted? should i need some calculation,and calculate
what?
If at some stage of the calculation you find that you a adding a large quantity
and a smaller one, you may neglect the small value if you are certain that
it will not affect the answer too much.
i am comfused with Q2 (iii) , stated that:
Assuming that there are no memory bandwidth oveheads at all, calculate the
time to transfer a single user segment, for an Ethernet speed of 100Mb/s,and
hence the "user transfer rate" in this case(the number of bytes transferred per
second as seen by the user).
how can i know the size of "a single user segment",is it stated in the
assignment2? Or, just assume a TCP segment formed by 1400 bytes user message to
calculate.
This should really be "single user message" rather than "single user segment"
(but a user message corresponds here to a single segment, and vice versa).
the payload 8*N in the ethernet message format... does the N come from adding
the octets from the transport layer down to network (including user data at
transport and the headers for both IP and TCP)??
Yes.
the total number of bits at the ethernet level... do we use this to find the
time for the message to be transmitted then take the time difference to find
the user data rate?
Use the number of bits to find the time to send the whole message with
overheads and then use a ratio (not a difference) to get the data
rate as seen by the user.
for the IPv6 the max number of octets in a packet is 1500... when we split it
in two.. would the second packet contain the TCP header as well and is used in
ethernet message format just like the first packet... then add the total number
of bits??
Thanks
There is only one TCP header in a segment. If the segment is split among
several IP packets, only the first packet contains the TCP header
(but each has its own IP header).
For question 2, the question says "the user message must be verified
as correct before it is acknowledge; if the received segment is 1160
octets, then the acknowledgement will also use a segment of 1160
octets." Does that mean if we send a segment of 1160 octets, we will be
getting another segment of 1160 octets as the acknowledgement?
For question 2, part 3, the question does not specify if an acknowledgement is
neccessary. Can we assume the acknowledgement is omitted in this case?
Read the introduction to Q2, which describes what happens for each and
every message.
basically for question one we can assume IEEE 802.3 format (ie 56 bits
preamble, 8 bits start delim, 48 dest addr ,48 src addr, 16 lenght,
8*N + 32 FCS) ?
In the handout you say :"... but ignore inter-frame gap" .
What's that ?Where can i find information on that ?
Does it matter if you don't know about something that I tell you to ignore?
It clearly can have no effect on the answer...
As Ethernet specifies a minimum idle period of 9.6 microseconds between
frames, the time to send a frame is about 9.6 us longer than
you might estimate by counting bits in the frame+preamble.
That extra time is the "inter-frame gap" and is what you can ignore.
i)Estimate the user data rate for packets 20,200,2000,10,000 .
The biggest number
user data that can be sent in IEEE 802.3 is 1500 octet.
So, this means that 2000
message will bw devided into two packets , right ?
It sounds plausible.
What is the lenght of the media(cable)?
Read the final comment in Q 1 (ii)
For question 1, the handout didn't say how much the octects for the
ethernet frame format, so can I say that preamble is 7 octects, and so
on, but if the data is less than the minimum number of data required, do
we need to includes the padding octects too, in the replied answers, you
said that when the segment is divided into smaller fragments, and that
one of the fragment include the tcp header, but not the others, does
that mean that the principle is the same for acknowledging packet, also
for the marking guidelines, how does marks allocation work, do we get
any marks if we get the logical reasoning, but the answers are wrong,
because of calculation errors?
Look at the first handout, from about page 16, for most of your answers.
You can certainly expect to get some marks for working the right way, even if
you do make a minor calculation error.
But if your answer doesn't explain what you are doing and how you are
thinking, it can be very hard to give marks for right ideas but wrong numbers.
sorry, forgot to ask you about the source and destination addresses for frame
format of ethernet, can I use 6 octects for both the source and destination
addresses?
See the first handout.
1. In part 1 first question, the size of user packet is original user message
size or the size of packet after attaching IP header and TCP header (IP header
+TCP header + original user message)?
The original message has appropriate headers added to it.
2. In part1 first question, you ask "Estimate 'the user data rate'
(not 'rates' here)for user packets of 20,200,2000 and 10000 bytes". Does
it mean the user is sending messages one by one (the user sends 20 bytes
first, then sends 200 bytes, then... without waiting for
acknowledgement)? or we need to calculate the user data rate for each
packet like in second question(In second question, you ask to estimate
the user data 'rates' for user messages of 500 and 10000 bytes')?
Calculate the user data rate separately for each one of the message
sizes given in the question.
(Q 1 (i) should be "...user messages of..." rather than
"...user packets of...").
3. In part1 second question, after the sender gets acknowledgement from
receiver and sends the next message, does the sender sends the same size
message repeatly or he will send different size message?
All user messages are 1400 bytes.
For question 1 part 1 in the assignment, do we need to calculate the time to
transmit the acknowledgement packet, and if so is the acknowledgemnt packet a
RR or a "piggy-backed", also, for part 2 question 1, does the header of the
segment contains the acknowledgement number, and what does bandwidth mean, does
it mean the maximum number of b/s the link can handle?
1. part 1 does not mention acknowledgements, so assume that data just
"streams" through the network with no acknowledgements.
2. part 2 DOES mention acknowledgements. You will find that the TCP header
has an acknowledgement number for reverse traffic, like N(R) of SDLC.
3. "Bandwidth" here means the number of bits or bytes that can be transferred
per second. You can increase the memory bandwidth by using a longer word
(more bits per transfer), or a faster memory (less time per transfer).
Most PCs transfer data in words of 4 bytes (8-byte words in a "64 bit" system).
In question 1 of the assignment, does the tcp segment get encapsulated
in a IP packet (tunneling), and that packet in turn encapsulated in a frame for
physical transmission, and for the 2nd part of the question 1, aren't the ipv6
overhead is 20 octets and not 40 octets?
The encapsulation is as you say (but there may be more than 1 IP packet to a
TCP segment).
But there is ALWAYS one IP packet per Ethernet frame,
(and one frame per IP packet.)
The IPv6 header is 40 octets; IPv4 is 20.
Is checksum considered as a memory bandwidth overheads?? To my understanding,
checksum is a mechanism for error detection and does not involve copying
messages from/to memory. However, the assignment question lists checksum under
the memory bandwidth overheads heading. Can you verify this please??
Usually the TCP checksum must be considered a memory overhead as it is done
by program and takes time.
It may be ignored in Q 2 (iii) "...no memory bandwidth overheads at all..."
but is (probably) required in part (iv).
Checksums (CRCs) at the Ethernet level are usually done by hardware
as the frame is sent and do not add any time overheads.
1. By your definition of "user data rate", if user packet is 2000 bytes,
can I think the user data rate is 2000 bytes per second regardless the Ethernet
transmission rate?
Somewhere, there must be a time to send a message ...
2. Dose user message will be transmitted eventually as following form?
Ethernet stuff(about 26 octets from your note) + IP header + TCP header +
user message.
Yes, but the TCP segment may be split into several IP packets, as stated
in other answers.
A major change is that the final part of Question 2
(top of page 3) is increased from 4 to 6 marks, to compensate for the
unattached 2 marks earlier in the question.
A revised assignment is on the Web
I'm still a bit uncertain with the concept of encapsulation/tunneling over
Ethernet.
If the "data length/type" field specifies a number less than 0x600, then the
information in the "data" field is user data regardless of whether the user
data may appear as though it is a LLC-SNAP header followed by strange data.
If the "data length/type" field specifies a number greater than 0x600, then the
information in the "data field" is control information instead of user data. If
this control information reads AA-AA-03 (LLC header), it indicates the
information is in fact strange data instead of control; and the type of strange
data is specified by the SNAP header that follows.
Encapsulation or tunnelling occurs when the payload of the Ethernet is not
the data, but is to have another level of interpretation.
Here the payload is not actually user data, but is marked as an IP frame
(by Ethernet 'type' or 802.3 LLC/SNAP header).
Thus the Ethernet payload must be interpreted as an IP packet, before the
user payload can be obtained.
(We actually need more levels of processing for TCP, but that is irrelevant
here.)
The essence of tunnelling is that we wrap a message of type A in an envelope
so that it can be sent as type B over a link that would not normally
handle type A messages.
The above is what I understand so far, but I'm not sure whether this is
correct. Can you please verify this??
The confusion is really historical.
ORIGINALLY, 802.3 used length/type <= 1500, and Ethernet used
length/type > 1500.
But then the 802.3 standard was extended to allow for both modes
(in line with what most people used anyway).
So the message can operate with either convention. With length <= 1500,
you must have the LLC & SNAP header (this is traditional IEEE 802.3 mode).
With length > 1500 (actually 1538) length becomes an encoded type,
using "well-known" type codes.
In the past I drew a very careful distinction between the two, but last
year found that IEEE 802.3 has absorbed the Ethernet convention, according
to the most recent standard, but some of the notes still reflect the old
emphasis.
I'm a bit confused with the difference between Ethernet and IEEE 802.3. The
text book suggests that they're exactly the same (Quote from text book - "IEEE
defined three formal standards: IEEE 802.3 for Ethernet..." on page 410 in 3rd
edition.) However, the lecture notes suggests that they're different as
Ethernet uses a "well known" value in the type field, whereas IEEE 802.3 uses
LLC-SNAP headers (slide 21 of the 1st set of notes).
Can you please verify whether they're the same thing. If not, what is the
difference.
See the above answer.
Could you please tell me what questions we should be able to answer by now ?
Can you please give us more examples which include more calculations on covered
topics of Assignment2.
(Considering very limited number of examples were provided so far during the
lectures.)
Thank you very much.
I'm sorry but at this stage of your studies (final year BSc) you should be
able to find suitable questions in this or other text books.
It seems like Part ii of Question 2 is missing from the assignment
handout and
from the web version. There's a 2 mark allocation shown on the page, but no
question associated with it.
You are correct. The mark should have been deleted, with its question!
Also, if you are pedantic, the rest of that question should be labelled (ii)
and (iii), rather than (iii) and (iv), but leave it the way it is.
TAKE THE FINAL PART OF THIS QUESTION UP TO 6 MARKS.
Hi, when TCP segments are fragmented (across multiple IP packets), does
each TCP segment need a header? (as is the case with fragmented IP packets).
Here we must be careful about terms - message, segment and packet.
* The user supplies a message for transmission.
* The user message has a single TCP header added to it and becomes a
TCP segment.
(A very long message may be split into several segments, each with its
own header, but not here.)
* The TCP segment is then split into several IP packets, each with its own IP
header. (The very first packet also includes the TCP header.)
* Each packet is placed on the medium (here Ethernet) with appropriate
envelope (headers and trailers) added to form the transmitted Frame.
Given the layers 1, 2, 3, 4 and user, the different data entities really exist
between layers (as SDUs and PDUs) as --
user - {message} - 4(TCP) - {segment} - 3(IP) - {packet} - 2(Ethernet)
- {frame} - 1(cable etc)
Hi, I have a few more questions about the assignment:
1) Does the 40 octet overhead for IP packets include the TCP overhead, or are
these seperate (resulting in a total overhead of 60 octets)?
See earlier discussion
2) What is meant by "minimal copying" in the 'Consider two cases, 1.' part of
question 2(iv)?
'Minimal copying' means that data is split by manipulating data structures
and pointers, so that transmission can occur directly from the original
user data.
By contrast, we could copy each byte of a TCP segment into the appropriate
IP packet, which means extra work and time.
3) For 'Consider two cases, 2', I have taken SDU to mean 'Service Data Unit',
however I am unsure of which part of the message this is. Is this the header of
the TCP segment, and hence should I take the explanation to mean that the TCP
header has been copied 4 times (in total)? I'm a bit confused about that one.
The SDU is the information *above* a layer of the protocol stack.
In the simplest case, the user message is a Service Data Unit (SDU) to the
TCP layer.
The TCP layer adds a TCP header to it, and the whole lot (Header + user data),
becomes a Protocol Data Unit (PDU) from the TCP layer (and the SDU to the
network, or IP, layer).
The IP layer may split a SDU into several PDUs, each with its own IP header.
Is frame common in any type of network? For example, ethernet and token ring.
I mean if there are frames in both kind of network. How about in ATM?
As in a lot of data communications, the term "frame" is widely used but poorly
defined.
I take it to be the unit transferred between the DataLink and Physical layers.
It usually includes physical addresses and delimiter codes.
ATM uses a special fixed-size frame called a "cell".
I found that I can set the duplex mode of network interface card in my
computer. So I think half-Duplex or Full-Duplex is operating in Data Link
layer of OSI. Could you please give me some ideas?
This probably refers to an 802.3/Ethernet interface.
Simpler (often older) interfaces can operate in either full duplex or half
duplex, so you may have to "pull back" a full duplex card to allow only
half duplex transfers.
I saw "parellel" on the back of my computer which is RS-232 port.
There are so many pins on it.
On the other hand, there are only four pins on USB port.
Why using USB port so intensively now?
The parallel port is NOT RS-232, but it may use a similar connector
(a 25 pin DB-25). So three points -
1. RS-232-C is a modem interface (where the modem is a separate box outside
the computer).
It allows a large set of control, clock and data signals for a full-duplex
transmission.
Information is sent serially by bit, and controls are on separate
connections
2. A parallel port transfers bits 8 or 16 at a time (in parallel, rather
than serially as in RS-232)
3. USB simply sends frames, of either data or control information.
By bringing all control signals into special frames it eliminates the pins
of RS-232, and by sending all data serially, it eliminates most of the
data pins of a parallel port.
(And the two outer pins of a USB connector are power, not signal...)
Read Shay (3rd Edition) from page 166 for more on USB.
A station is sending a frame to a destination station, meanwhile a collision
occurs, what happens to the frame if the destination station has already
received half of the frame? Will the destination station drop the half frame
or try to correct the rest?
Wait and see .... We cover this later
I have a couple of questions about Q1 of Assignment #2.
Q1 part (i) :
From what I understand each user message has 60 octets of Header ( 20 octets
comes from the segment and another 40 comes from the packet ) and does not
contain any trailers. (Can't find any corresponding numbers in the problem for
part (i) ).
There are no trailers, but the overheads can be at either end, depending
on where the protocol designer puts them.
Moreover, distance D and acknowledgement A are not known. (Not given to be
more specific ).
The note to Question 1 (ii) covers this.
Also, wanted to know whether or not I am right to assume that the signal
velocity is V=2*10^8 m/s?
You could, but is it necessary?
Is "user data rate" same as "effective or visible user data rate" ? ( I am
trying to link all give information to the formulae given on page 19. ) , but
some of the information ( such as D, A, T, and V ) is missing.
Remember what I said, many times, about working from first principles.
Learn the ideas behind the formulae, rather than the formulae themselves.
Does this mean that we calculate without them?
Probably they were not given because they are not needed
For , part (ii) of the Q1.
Do we need to find Total time before next message may be sent or just user data
rate?
The question says "the user data rate".
You will probably find that the time between sending messages is a major step
in getting the final answer.