Subject: Comments on draft-ietf-pilc-2.5g3g-04 part 2 (NiTs)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 01 Nov 2001 10:24:55 +0000

Comments on draft-ietf-pilc-2.5g3g-04
part 2, 31 October 2001

I include here my other comments, mostly small NiTs.

Hope that is helpful,

Gorry Fairhurst

---

page 3 section 2 para 3. 
Corrections to English:
RLC uses protocol data units (PDUs) with 
-- insert "a"
16 bit RLC header.  There is an implementation with
-- insert "a"
336 bit
-- delete the "s long"
PDU.

page 3 section 2 para 3. 
"The SDU (IP packet) is fragmented into PDUs for
   transmission by RLC."
It may be useful to make a forward reference to 
section 3.1.4 after the word "fragmented".

page 3 section 2 para 5. 
The term "status report" type acknowledgements is what is
more generally known as checkpoint ARQ. This may be useful
to mention and suggest refer to [9].

page 3 section 2 para 5. 
Add full stop at end of paragraph.

page 4 para 1.
This seems to repeat the previous statement about fragmentation,
suggest the ID either says this is "transparent" fragmentation and
be clearer about the PDUs created - or omit. At the moment
it makes hard reading.

page 4 para 2.
This paragraph doesn't read well, could it be combined with
the previous to provide a summary?

page 5 section 3.1.1
A reference needed to the RFC for TCP standardm(s).

page 5 section 3.1.1
Probably worth stressing that what matters is the end to end
path BDP between end hosts, not just the link BDP. Although,
often in 2.5G/3G applications the link BDP may often predominate.

page 6 para 2
Some confusion about IPv4 and v6 seems to have crept in:
At the end, the ID suggests an example of 576B - this should be 
for IPv4, a similar number for v6 is 1280B.
The ID says at the end "such as 1500 B IPv4 packets on Ethernet"
- the ID can omit the "v4", since this applies equally to v4 and v6.

page 6 para 2
Suggest remove "although" in the last sentence, and start a new 
sentence?

page 8 section 4
The open issues section is not so well laid out. Perhaps one could
add some section numbers and titles showing the relevant areas, e.g.:
"Link mechanisms"
"TCP end host modifications"

page 8 para 1 last sentence

"in general"
perhaps in the "internet in general" would be clearer?

page 8 para 2
"safes transmission" - should be "saves transmission" (same mistake in -03)

page 8 para 3 line 1
"Finding ways to avoid" - actually I think it may the setup
delay which you are minimising, and that this is a function
of the round trip path delay...

page 8 para 3 line 1
"the round-trip times" - may be better saying "the path round
trip time"

page 8 para 4 last line
"its security concerns" perhaps "known security concerns" may be
better?

page 8 last para line 1
"spurious timeouts" should be "spurious TCP timeouts"
*** It may be useful to refer also to SLOW here? [RFC3150] 

page 8 last para line 1
"packet reordering" should be "significant packet reordering"
*** It would be useful to refer also to LINK or ARQ here? [9,11]
*** (e.g. greater than DupACK Threshold) - small reordering is currently
*** observed on many Internet paths.

page 8 last para last line
"the retransmission timer" should be "the TCP retransmission timer" 

page 9 para 1 line 5
"coverage hole" - not a term I am familiar with, perhaps it may
be better to add a few words explaining this?

Are acknowledgements normally appendices?

The English really still needs a run through by someone to make it
easier to read.