Subject: [Tsvwg] Re: comments on the ecn alternative draft

From: Sally Floyd <[email-masked]>
Date: Thu, 11 Aug 2005 07:46:42 -0700

Mark -

Many thanks for the feedback.   I have made all of the
suggested changes (details are below).

I have put the revised draft at
  http://www.icir.org/floyd/draft-floyd-ecn-alternates-02a.txt,
  http://www.icir.org/floyd/draft-floyd-ecn-alternates-02a.ps,
and the diffs at:
  http://www.icir.org/floyd/draft-floyd-ecn-alternates-02a.diffs.

I will ask Jon and Allison if I can send it in as
draft-ietf-tsvwg-ecn-alternates-00.txt.  And then I think
it is ready for Working Group Last Call...

- Sally
http://www.icir.org/floyd/
------------------------------------------------------------------

>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.

Good point.  Done.

>  * 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.))

Yep.  Done.

>  * 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.

Hmmm.  Do you mean a policer for the incremental-deployment stage
to ensure conformance with the default semantics with the
default-ECN router along the path, or a policer to ensure
conformance with the alternate-ECN semantics?
For the second, I added a sentence to the end of Section 5.1.

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

Done.

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

Done.

>  * 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.

Done.
  
>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.

Many thanks.

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 Aug 2005 10:00:40 +0100

One more thought on one of Marks list of topics...

>>    measurements on how quickly routes change in the Internet.))

- 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.

Gorry

---

From: Mark Allman <[email-masked]>
Date: Tue, 23 Aug 2005 07:04:54 -0400

> For the second, I added a sentence to the end of Section 5.1.

Yep, the second.

Thanks,
allman