Subject: [ippm] WGLC on draft-ietf-ippm-reordering-07.txt

From: "Henk Uijterwaal (RIPE NCC)" <[email-masked]>
Date: Thu, 7 Oct 2004 20:02:38 +0200 (CEST)

IPPM group,

The latest draft of "Packet Reordering Metric for IPPM" has all the fixes
and changes suggested on this list and at previous IETF meetings.

The chairs propose a Working Group last-call for this document,
draft-ietf-ippm-reordering-07.txt

Please comment on whether or not you feel that this Internet-Draft should
be given to the Area Directors and the IESG for consideration as a
Proposed Standard RFC.

Submit your comments to the IPPM mailing list or to the chairs or I-D
authors as you feel appropriate (although public comments are preferred).
This Working Group last call will end on Friday, October 29, 2004
at 9:00 GMT.

One pointer for the document is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-07.txt

The chairs,

Matt & Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

In a room with a window in the corner, I found truth.            (Ian Curtis)

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Mark Allman <[email-masked]>
Date: Fri, 29 Oct 2004 22:58:33 -0400

Folks-

Reading this document for the first time in a long time.  Alas, early
review is better than later review.  But, review is better than no
review.

I don't think this document is yet ready for PS.  My comments:

  * In the first sentence of section 2 you note that "ordered delivery
    is a property of successful packet transfer".  Later you note that
    "packet order is not expected to change during transfer".  I
    disagree with the first statement and mostly with the spirit in
    which the second is made.  I think this document should specifically
    note that, in fact, packet reordering is explicitly tolerated by
    Internet protocols.  That is, there is actually no expectation of
    order.  One might argue that there is an expectation of reasonable
    ordering -- i.e., that packets should not be delayed by minutes,
    say.  But, I think the document really needs to note that reordering
    is not something "unexpected" in the network.  Of course,
    applications will have more or less ability to cope with reordering,
    depending on their requirements.  But, that is a bit different from
    this being considered an anomalous event.

  * Section 2.2 is troubling.

    First, the bullet with that says a reordering metric MUST "have one
    or more relevant applications, such as receiver design or network
    characterization".  Isn't this largely a content-free requirement?
    Damn near anything can be considered "network characterization",
    right?  I just think that this requirement either needs reworded
    (maybe I am just not Getting It) or just dropped --- because it
    really adds nothing as it currently sits, IMO.

    Second, the document notes that reordering metrics MUST "work with
    Poisson and Periodic test streams".  However, one of your
    "desirable" items will never be met... "have relevance to TCP
    performance".  TCP's sending pattern is neither Poisson nor Periodic
    and it is not clear to me whether any of your metrics have any
    relevance to TCP.  (More below.)

  * In section 3 ... I am just confused.

    First, I'd note that sequence numbers must be unique and increasing
    (modulo the discussion on wrap, later in the document, of course).
    The part about being unique should be stated for the time-based
    scheme whereby the period of the stream could well be faster than
    some clock tick (i.e., one could be using two different clocks or
    gross granularity in the packets and finer granularity in the
    scheduling or whatever).

    But, let me not get ahead of myself here.  I think this whole
    document could be simplified by using only message numbers in the
    test stream.  In particular, using a timestamp is a thorny notion.
    How is the receiver supposed to have a good handle on what to expect
    next?  There are tons of things that could mess up that notion (NTP
    could change the time on the sender, the sender could be busy and
    a transmission could be delayed a tad, etc., etc.).  And, while I
    can see how the receiver could make a guess at the expected time in
    a Periodic stream, I have no idea how that works in a Poisson
    stream.

    Byte counts are just needless complexity for this section, too it
    would seem.  The test stream contains packets of a given size,
    right?  If so, then the byte counts can easily be calculated from
    the packet counts in the metrics where we need byte counts (and,
    those metrics are fine - good even) and we can just use packet
    counts here to simplify things.

    I think that it's fine to include a timestamp and include or derive
    a byte count.  But, for the sake of simplicity it seems like
    requiring a packet count and using that as the key determiner of
    out-of-orderness is the way to go.  If not, then I think a whole lot
    more discussion of the pitfalls of these other schemes is required
    to give people a solid understanding of the implications of their
    choices.

  * Section 4.4

    There are these extrapolations that the document calls for that kind
    of bug me.  This is one case.  From what I can tell, the packet
    streams being called for here are of uniform packet sizes.  But, in
    this section you try to use the byte counts to determine a buffer
    size in terms of bytes, which may be useful to an application that
    sends varying sized packets (this is stated in the document).
    Finding the buffering requirement is a useful thing to want to do.

    However, there is not even the mention that the test stream could
    potentially be a poor predictor of the reordering (and therefore the
    buffer size) required by some application with different sized
    segments.  We have some early results that suggest small segments
    fall victim to reordering more often than large segments, for
    instance.  I think a note is in order to that effect here.  I think
    this document needs a very careful pass to add such notes anywhere
    where it advocates for extrapolating something from the measurements
    that is not actually being measured.  Inferring is a tricky game.
    It's hard to get right and easy to get wrong.

  * Section 5

    Similar to the above, this section is just trying to reach too far,
    I think.  But, this one is even worse.  I think section 5 is largely
    just bogus.  There is a caveat in this section:

	We note that the definition of n-reordering cannot predict the
	exact number of packets unnecessarily retransmitted by a TCP
	sender under some circumstances, such as cases with
	closely-spaced reordered singletons. The definition is less
	complicated than a TCP implementation where both time and
	position influence the sender's behavior.

    But, this doesn't even get to the heart of the matter.  The real
    issue here is that using Periodic or Poisson sending patterns in no
    way matches or even approximates TCP's sending pattern.  And, so
    n-reordering cannot predict the number of retransmissions because it
    is not observing the same kinds of reordering phenomena that a TCP
    stream would.  This is another example of trying to infer too much.

    If this definition were for a stream of packets sent using some BTC
    tool, then OK.  Now, I'd buy it.  And, I understand that this
    document does not preclude doing that.  However, it also doesn't
    suggest it -- or, better yet, require it.  In fact, quite the
    opposite the draft indicates that it is fine to use this metric with
    Periodic or Poisson because all metrics must "work" with those two
    stream types.

  * Section 6

    It is not clear to me why (in a test stream) there would be
    "retransmits".  The document notes that one must take care to
    disambiguate original transmissions and retransmissions.  But, why
    would there be such complexity in a test stream?

    At the risk of being redundant here, this section discusses TCP
    advertised window provisioning and discusses segments that are
    "sufficiently beyond" the window and etc.  This again shows the
    discrepancy with TCP.  Unless something is pretty broken, TCP does
    not send segments beyond the advertised window.  So, projecting
    anything that happens in the great beyond is pretty thorny it seems
    to me.

I am happy to iterate on any/all of the above to clarify or flesh out or
whatever.

Thanks!

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: Al Morton <[email-masked]>
Date: Sat, 30 Oct 2004 12:53:50 -0400

Mark,
Thanks for your careful review.

>review is better than later review.  But, review is better than no

Agreed.  Almost all of your comments have the virtue of being "new",
so the memo will be improved when we're done.  Worth the trip.

>... <many good comments deleted> ...

Great, your comments seem clear to me.
I'll start working through by sections or topics,
which ever makes the most sense, and hopefully we'll have most
resolutions agreed by next week.

thanks again,
Al