comments on draft-ietf-pilc-link-arq-issues-01.txt

["Gary Kenward" <[e-mail]>]

Hello. Gorry Fairhurst asked me if I had any comments on the latest version
of ARQ draft, and suggested that I post them directly to the list.

I have been preoccupied elsewhere lately, so this is a bit of a rushed
review. 
Hopefully, my comments will be of help to the draft editors and the PILC 
working group.

First of all, given the complexity of ARQ/MAC protocols, the draft does a
really
good job of covering many issues. 

(Below, I use the notation "pg#" for "page #", "s#.#" for "section #.#",
"p#"
for "paragraph #" and "pt#" for "point #")

pg3, s1.3, ptb:
b. Link ARQ can operate on individual frames, which are much smaller than IP
datagrams and may therefore permit more efficient recovery in terms of
repetition of data after occasional losses. For any specific target error
rate there is an optimal trade-off between header overhead and frame size. 
The last sentence does not fit into the context. The relationship betwee
header overhead ARQ is inferred, not explained. It may have been presumed
that ARQ implies additional header overhead, which is not always the case.
pg4, s1.4, p1:
Two basic categories of ARQ retransmission process are widely used: 
I don't have quantitative survey numbers, but I don't believe that this
statement is generally true. At the very least, it seems to me to be
misleading when referring to link layer designs (the prevalance of TCP
definitely would bias any survey of ARQ processes used). 
There are other very important ARQ techniques, such as selective ARQ and
Go-back-N ARQ. I suspect that selective ARQ is also a common link layer
solution. Certainly, at the link layer it has many advantages over either
window or stop-and-wait ARQ.
pg4, s1.4.2, p1: The phrase "according to a modulus" needs to be explained
better. 
pg4, s1.4.2, p3: The term "bandwidth-persistence" has not been defined, and
so it is difficult to understand the assertion made in the sentence.
pg5, s1.5, ptd: Perhaps there is a physicist on the list that can clarify,
but the phrase "caused by the speed of light in the channel medium" should
be "limited by the speed of the electromagnetic signal in the channel
medium" or something similar.
pg5, s1.5, pte: Does "Processing" include Forward Error Control? FEC
processing often exceeds many of the other factors noted. Indeed, FEC should
probably be listed separately (in hybrid ARQ schemes, FEC processing is also
a source of delay jitter). 
pg5, s1.5, p2: "When link ARQ is used, steps a., b., c., d. and e. may be
repeated" - many ARQ schemes re-queue the frames, some change the FEC, some
require different buffering for re-assembly (called by some "block ARQ" or
"memory ARQ").
pg 5, s2, p2: Here is the definition of persistency needed to understand the
term "bandwidth-persistence". However, this definition ignores the often
larger delays imposed on retransmissions due to backoff algorithms and/or
re-queuing (as an example, the exponential backoff used in Ethernet, or the
incremental backoff used in CDMA2000; the latter being on the order of 300 -
600 milliseconds).
p6, s2, p3 and p4: These paragraphs on "perfect reliability" are misleading.
They tend to imply that ARQ is not required at all. The text should be
modified to explain that ARQ is required to improve reliability, but that
this reliability need not be 100%. It is my understanding that one rule of
thumb states that the performance of TCP starts to degrade if the IP packet
loss exceeds 1% - end-to-end.
p6, s2.1, p1: Again, I have not taken a survey of late, but I don't agree
that "Most well-known link protocols are reliable protocols, which use
perfectly-persistent ARQ". Examples are CSMA/CD and CDMA2000.
p8, s2.4, table: I'm going to have to give this much more thought, but the
idea that link persistence is related to some multiple of the RTT doesn't
work for me. The major difficulty I have has to do with the other delays,
noteable backoff and re-queuing, that I mentioned. Specifically, I refer to
Ethernet's version of CSMA/CD, where the timing of retransmissions is much
greater then the RTT.
p9: Packet ordering: some mention should be made about the relationship
between reordering, delay and persistence. Reordering introduces large(r)
buffers at the destination, which will be much larger if the re-transmission
delays and the number of retransmissions are larger (you have to store more
copies of packets to ensure that you can rebuild the ordered stream).
p10, s3.2, pta: I don't agree that the "identification scheme" for DS is
"much more complex". In some ways, it is simpler. Certainly, the semantics
of PHBs etc. is more complext, but the identification scheme is not. It is
flat, and in fact, the link layer interpretation of the DSCP is not
necessarly tied to PHBs.
That's all for now, I hope this has been useful.
Regards,
Gary Kenward