Please see comments below on Link -09. I find the text mostly
correct and a significant improvement on previous drafts.
Comments are arranged in section order.
Best wishes,
Gorry Fairhurst
------------
OVERALL TERMINOLOGY!
It may be good to replace "packet" with "IP packet" unless you
specifically refer to IPv4 or IPv6 - since some
subnetworks also call the SNDU a "packet" ;-).
BE CAREFUL though in the section on "buffering" since packet
refers to either of the two cases!!!
"Router" or "Gateway"??????
- Both terms are used. I would suggest "router"?
-----------
INTRODUCTION
ENGLISH
Introduction para 5, after list of 3 points - you start a sentence with "But",
consider rephrasing to remove this.
QUERY: "rely" or "benefit significantly from"?
In the sentence which follows - does IP QoS and mcast "rely" on these or
may it just "benefit" from support? - I'd argue you can multicast with
no
support, it's just inefficient - and QoS can be done solely with queues
- it's just better if the subnet also has a notion of QoS. If this is really
so, you may want to add these comments to the later para starting "However".
QUERY TERM: "subnetwork?"
We have been engaged in a deep and confusing discussion with an IESG member
- part of which turned out to originate in loose definitions of terms. I
think we *should* define "subnetwork" explicitly in the introduction to avoid
such problems.
------------
MTU
QUERY TERMS: "Router fragmentation" and "internal fragmentation"
para 6
I don't think the term "router fragmentation" is clear.
In the ARQ draft, we say "Explicit network layer IP fragmentation" instead
of "router fragmentation" - to make sure we do expect transparent link
fragmentation to still occur in some subnetworks.
Here's our current text to compare with the link draft
"internal fragmentation":
"To allow for efficient use of the channel, the maximum link frame size
may therefore be considerably lower than the maximum IP datagram size
expressed in the IP Maximum Transmission Unit (MTU). Each frame will
then contain only a fraction of an IP packet and transparent implicit
fragmentation of the IP datagram is used [DRAFTKARN01]. A smaller
frame size introduces more frame header overhead per payload byte
transported."
- In this ID, it may be better to use "subnetwork frame".
- I haven't come across the term "internal fragmentation" - I guess
"Link" or "transparent" fragmentation are more common terms. Is
"subnetwork fragmentation" the best term for this ID?
Last para of section.
"IP fragmentation" --> should be the same terms as you finally choose
for "router fragmentation".
------------
Choosing the MTU
para 6 starting "A third example..."
"internal fragmentation" -> "subnetwork fragmentation" (see above).
------------
Framing
Para starting "in AAL5.."
This para should be joined to previous.
Word "cel" =-> "cell"
------------
Connection-oriented
Para 1 - Missing reference for TCP [RFC793].
Para 2 - Are these subnetwork "nodes" or "IP routers"???
- I think the text is talking about the number of IP Routers
in a subnetwork, not the number of internal nodes.
------------
Broadcast
BEWARE of "point-to-point" and "shared" - that was one of the terms
that caused a lot of questions in ARQ. This is *NOT* the same as a
point-to-point PPP connection! We now use the term "dedicated link"
instead of "point-to-point".
------------
BOD
para 1.
"Spectrum resources" -> replace by "spectrum resources (i.e., the shared
channel that the radio link uses)"
----------
TCP v LINK...
ENGLISH" Style becomes very tutorial in this section:
Para 2.
"For largely historical reasons"
- doesn't seem to add anything - delete?
"ARQ has been used for many decades..." - delete?
"Unlike FEC..." - delete?
- replace next "It" by "ARQ".
"FEC is also..." - delete?
- This section is still probably too long, given we have another ID
on the subject - but *I'm* not doing the pruning...
---------
Recovery
NOTE: IN ARQ we now define "outage" as "
outage (i.e. a period during which the link loses all or virtually all
frames,
until the link is restored)". Suggest you replace "link"
by "subnetwork" and insert this at the start.
ENGLISH "And"
Para 3, sentence starts with "And" - could be rephrased.
---------
How TCP works
NOTE: This section still reads strange since it come in the middle of the
document, well after we have talked about many TCP issues!!!
para starting "TCP Assumes"
Combine paras 2 and 3 (next).
para 9: " A new technique"
This has the use of "MUST" etc in the paragraph - no other paragraphs in
this ID use this style. - suggest you replace with normal type.
-----------
Analysis
NOTE: The example seems awkward appearing at the mid-point of
the document.
Observation 2:
"link-layer" -> "subnetwork"
"bit error rate" -> "bit error ratio"
--- this is WRONG, it is NOT a rate!
"PACKET_SIZE" really is a very ***BAD*** term (I said this before).
Since we can and often **DO** have transparent link fragmentation,
this is not a good way to talk about things in general.
You need to EXPLICITLY say that you "consider only the case where
one packet is ent per subnetwork frame (i.e. no transparent link
fragmentation)".
You **SHOULD*** also change PACKET_SIZE to FRAME_SIZE - since this
is clearly not just an IP packet!!! This current text is very
misleading and seems at first sight to contradict other parts
of the document - fixing the terminology will make the real
issue clear.
---------
QoS
para 9 is just one sentence long. - Combine with previous?
para 9 : ToS isn't defined - it should be:
"Type of Service (ToS) [RFC791]"
---------
Delay
para 5 is just one sentence long. - Combine with previous?
para 5: Starts with "But" - delete the "But".
para 11 is just one sentence long. - Combine with previous?
---------
Bandwidth Asym
para 1, line 6
insert "," after acknowledgements" near end of the line.
---------
Buffering
para 2
"a complete IP datagram or a subnetwork packet"
- terminology problem, suggest:
"a complete IP packet, or a subnetwork frame"
----------
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 12:11:39 EST