[Tmrg] Comments on in draft-irtf-tmrg-metrics-10.txt

[lachlan.andrew at gmail.com (Lachlan Andrew)]

Greetings Sally,

Here are some further comments on   draft-irtf-tmrg-metrics-10.txt.

- Section 2.1.1 Throughput
introduces the difference between throughput and goodput, and then
says that maximizing throughput is desirable.  This makes it sound as
if throughput is more important than goodput, which I don't think was
the intention.

Perhaps replace "...because they can't be re-assembled into complete
packets, and the like."
by "...because they can't be re-assembled into complete packets, and
the like.  Except where clearly stated, this document refers to both
throughput and goodput generically as 'throughput'." or rephrase the
rest of the section/document in terms of maximizing goodput.

- Section 2.4 Robustness for Challenging Environments
defines goodput as a *fraction* of the sent data which is received,
which seems to contradict the definition in 2.1.1 which is the *total
amount* of data which is received.

I think that the definition from 2.1.1 is more standard, and would
recommend rephrasing the paragraph as:
   "Goodput: For wireless networks, goodput can be a useful metric,
    where goodput can be defined as the total amount of useful data
    delivered to users.  A high ratio of goodput to sent data indicates
    an efficient use of the radio spectrum and lower interference with
    other users."

Another couple of comments:

- Section 2.1.2  Delay
It might be worth mentioning that "delay" can also include the time
spent queued at the sender due to window flow control, as well as at
network queues and retransmissions.  This is often the dominant source
of socket-layer delay.  (This relates to Mark Allman's recent comments
that spurious timeouts have a cost in terms of window reduction which
must be weighed against the reduced waiting time of short RTO.)

-  Section 2.1.2  Delay
When discussing "router-based" vs "flow-based" delay, it might be good
to mention that "router-based" delay affects competing traffic, while
"flow-based" delay does not.  Thus, router-based delay induced by bulk
data transfer applications is important, even if they aren't
interested in per-packet transfer times.

Perhaps the section could be rephrased as:
    Like throughput, delay can be measured as a router-based metric of
    queueing delay over time, or as a flow-based metric in terms of per-
    packet transfer times.  For any rate controlled transfer, the per-packet
    transfer time will include time between when the application generates
    the packet and when the protocol allows it to be first sent.  For reliable
    transfer, the per-packet transfer time seen by the application includes
    the possible delay of retransmitting a lost packet.

    Users of bulk data transfer applications might care about per-packet
    transfer times only in so far as they affect the per-connection
    transfer time.  On the other end of the spectrum, for users of
    streaming media, per-packet delay can be a significant concern.
    Note that in some cases the average delay might not capture the
    metric of interest to the users; for example, some users might care
    about the worst-case delay, or about the tail of the delay
    distribution.

    Note that queueing delay is experienced by all flows sharing a link.
    Thus, bulk data transfer applications should still seek to achieve
    low queueing delay for the benefit of cross traffic, even if not for
    their own benefit.

- (Nit picking)  [F98] unnecessarily duplicates  [KMT98].  The
reference to [F98] in 2.3.2 should also be replaced by [KMT98].

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: [phone]    Fax: [phone]