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.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:28 EST