draft-ietf-pilc-link-09 - comments.

[Gorry Fairhurst <[e-mail]>]

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"

----------