Subject: [Tsvwg] comments on the ecn alternative draft

From: Mark Allman <[email-masked]>
Date: Mon, 08 Aug 2005 09:57:56 -0400

Sally-

I read through your ECN alternatives i-d.  Generally speaking, I think
it's nicely done.  I have a few wonderings ...

  + Rather than discussing the "TCP friendliness" of traffic using some
    sort of alternate ECN semantics, I wonder if it would be better to
    further generalized to being friendly to "IETF conformant"
    congestion control, or some such language.  In other words, why tie
    this to TCP-friendliness instead of simply whatever the standards
    process has sanctioned?

    Things like HS-TCP are not TCP friendly [and, I think that is a fine
    state of affairs and am not at all arguing it] and so if an
    alternate ECN scheme were somehow different in a way that is similar
    to how HS-TCP is different (i.e., in a region where "TCP
    friendliness" doesn't make a ton of sense) then maybe it would be OK
    to not be TCP friendly.

  * In 4.2 I would recommend adding a few more words that explicitly say
    that connections need to monitor the capabilities of the routers on
    the path to ensure they all continue to understand alternate
    semantics.  I think this is what you mean by being robust to path
    changes.  But, path changes are allowed and it's not just from load
    balancers (which I don't see as a big deal in this case).  So, I'd
    think a note that says some sort of "continuous" monitoring is in
    order would be useful.  (For some definition of "continuous".  I
    don't think that has to mean every packet has to be a test of the
    path.  And, I don't think you'd have to nail down what it means in
    this document.  But, I think some words to this effect would be
    useful.  (E.g., I might buy using timescales derived from
    measurements on how quickly routes change in the Internet.))

  * I wonder about noting that an alternate ECN router could include a
    policer to ensure that the end system was correctly interpreting the
    ECN marks.  I.e., some of the burden for ensuring that alternate ECN
    is "playing nice" could be shifted to something we know groks
    alternate ECN.

  * 4.3, end of paragraph 8: suggest citing the ECN nonce RFC here.

  * 4.3, last paragraph: "higher that would" --> "higher than would"

  * In 5.1 I would suggest an explicit note that the current ECN nonce
    is agnostic to the semantics of ECN, as long as ECT(0) and ECT(1)
    mean the same thing and are put on packets randomly.  Basically, a
    note here that says that alternate schemes can just leverage the
    current nonce by retaining these codepoints.  It just seems useful
    to remind people in very explicit terms that the current nonce has
    nothing to do with the current semantics.

I don't think any of the above are huge comments that have to be
addressed.  I hope they are useful.  But, overall I like the document,
think that the angles are all covered and think it's in good shape.  I
think it could be called "done" anytime.

allman

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

---

From: Sally Floyd <[email-masked]>
Date: Fri, 12 Aug 2005 09:46:37 -0700

Gorry -

>One more thought on one of Marks list of topics...
...
>- I suggest this also needs a phrase to catch the case of a change of
>configuration/state/policy within an intermediate router along an existing
>path (e.g. A restart of the configuration image, a policy that triggers on
>some other condition, time-of-day, QoS profile, etc) - In other words it
>needs to validate the path which is more than monitoring route changes, it
>also responding to changes in router behaviour along an existing path. This
>is classic "soft-state" as in PIM, PMTUD, etc.

Thanks, I have modified it as follows:

 Such a mechanism should be robust in the presence of paths with
 multi-path routing, and in the presence of routing or configuration
 changes along the path while the connection is in use.  In particular,
 if this option is used, connections could include some form of
 monitoring for changes in path behavior, and/or periodic monitoring  
 that all routers along the path continue to understand the alternate-ECN
 semantics.

http://www.icir.org/floyd/papers/draft-floyd-ecn-alternates-02b.txt
http://www.icir.org/floyd/papers/draft-floyd-ecn-alternates-02b.ps

- Sally