Subject: [Tsvwg] thoughts on the rt-ecn draft

From: Mark Allman <[email-masked]>
Date: Thu, 11 Aug 2005 13:04:25 -0400

Folks-

I read through the real-time ECN i-d (draft-babiarz-tsvwg-rtecn-04.txt)
and have some thoughts:

  + Overall I found this i-d somewhat hard to read.  It seems like it
    could have been more precisely written and in about half the space.
    I came away from reading this document and don't feel like I fully
    get it.  That's not a good place for a specification to be, IMO.  I
    would encourage the authors to hone their message.  (Or, maybe I am
    thick.) 

  + In section 2 you note that it is desirable to keep congestion
    information in the stock IP headers and not use options for
    performance reasons.  You might also note that in many cases,
    packets containing IP options are dropped by today's network.  See:

      Alberto Medina, Mark Allman, Sally Floyd.  Measuring the Evolution
      of Transport Protocols in the Internet. ACM Computer Communication
      Review, 35(2), April 2005.
      http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps

  + It is just not clear to me from reading the document who is in
    control of things.  You refer to the "application", but is that
    really the end user's application on their workstation?

    I think what might be throwing me off here is that you talk about
    "admitting a flow".  Who makes that decision?  Is it some entity
    that is not the end host?  Or, is it the end host after it receives
    feedback from the network (in which case, it would see as though in
    some sense the flow has been admitted - or, probationally admitted
    or something).

  + The congestion response given in the document is all a little too
    loose for me to swallow, I think.

    First, simply not starting a new flow when there is already
    congestion doesn't do anything to actually relieve the congestion.
    It could be worse if you did admit the flow, of course.  But, if
    we're already in a congested state then this alone doesn't help all
    that much.

    So, then the goes on to say that established flows should "slow
    down" their sending rate or terminate all-together.

        (1) The draft purports to be for inelastic flows.  So, how does
            an inelastic flow "slow down"?

        (2) If we assume that the flows can slow down then simply saying
            "slow down" is not all that satisfying.  How much should
            they slow down?  RFC3168 ECN says that ECN marks are akin to
            drops and so you slow down just as you do in the face of
            drops.  That is a pretty solid rule.  "Slow down" is not a
            solid rule.

        (3) It is not clear to me that end hosts (let alone
            *applications*) are going to terminate a flow because of an
            indication from the network.  Slowing down (ala TCP) such
            that some amount of traffic still gets through is a far cry
            from flows just stopping all transmission.  That seems quite
            impractical to me.  If this was to be done by some sort of
            third-party that wasn't the end system then I might buy it.
            But, it still seems a stretch.

  + In section 4.1 you use words like "path is valid".  But, what you
    really mean is that there is one node along the path that seems to
    be doing the right thing.  Right?  You have no way to actually judge
    the entire path.  If a problem occurs on every packet transmission
    then OK.  But, intermittent problems may well not be caught.  This
    probing notion seems weak to me.

  + I don't understand the "detecting cheaters" business.  

        (1) You are detecting cheaters in the middle of the network, not
            at the receiver.  But, I don't worry much about the middle
            of the network -- it is the end points that have the
            incentive to cheat.  At the very least you should quite
            explicitly note that the scheme cannot detect receiver
            cheating.

            [This is a departure from the ECN nonce which does protect
             against end host cheating.]

        (2) Does this scheme even work?  You very explicitly lay out
            which packets are doing to be used for cheating detection.
            Why couldn't a determined cheater figure out which packets
            these are and not mess with them?  I don't follow.

        (3) Step 5B on page 16 baffles me.  If we find a cheater then we
            simply go back to step 3 and move on to scheduling another
            attempt to catch a cheater?  Huh?  That makes no sense to me
            at all.

  + The scheme might work to detect RFC3168 ECN routers.  Might.  You;d
    have to be probing when such a queue was congested.  So, you might
    detect by dumb luck.

  + Section 6 ought to be an appendix, I think (since you don't
    recommend it).

Overall I don't think this scheme is solidly specified (in this
document, anyway) and so I am left wondering whether it will nicely
co-exist with RFC3168 ECN or not.  Lots of questions still remain for
me.  I hope the above comments are somewhat helpful.

allman

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

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 11 Aug 2005 14:01:29 -0400

Mark:
Thank you very much for your comments.
Please see my responses below in-line.
-- Kwok --

>     would encourage the authors to hone their message.  (Or, maybe I am

We have added much more info into this doc then we initially have.
We will do some cleaning up before publishing the next version.
Thanks for pointing this out.

>       http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps

Thank you for the pointer.

>     some sense the flow has been admitted - or, probationally admitted

We are using SIP as the signaling protocol in the application layer for session
control and hence the "flow".  We want to let the application (SIP control) 
to make
that decision.  Now the SIP session decision may or may not be made in the 
end host.
Hence we did not indicate this, may be we should clarify this.
We want to have the ECN field carry the network conditions as input for 
making the
SIP session decision.
We also think that SIP is only one of possible application signaling 
protocol that can
be helped by the network condition provided in the ECN field.  Hence we did 
not spell
that out in this draft, but we have another draft that provided the 
application usage
of the ECN field information in
http://www.ietf.org/internet-drafts/draft-alexander-rtecn-use-cases-00.txt
Hope the information in the use cases draft will help answer some of the 
question you
may have wrt how the decision in the application using RT-ECN is made.

>     we're already in a congested state then this alone doesn't help all

We are taking the traffic level that start triggering the marking of CE to 
be before any
packets start extending the queues handling this traffic flow.  This is for 
real time
traffic that does not want the queues to build up causing too much delay 
and jitter.
Hence the existing traffic level before the new flow is admitted does not 
exhibit congestion
condition.  The new flow (if admitted) will start exhibiting congestion 
condition, but not
to the point that excessive delay and jitter does damage to already 
admitted sessions.
Please notice that delay and jitter condition is shared by all flows 
handled by the same
queue (or forwarding behavior) and one of our goals is to not admit new 
flows if it will
damage/worsen the delay and jitter condition of admitted flows.  Hence the 
admission
control function does help to prevent the congestion state from 
happening.  We also
talked about preemption to relieve congestion condition if just admission 
control is
not sufficient, or there are more important flows/sessions that need to be 
allowed to
use the network resources in the expense of already admitted flows/sessions.
Please let me know if the above explanation sufficiently answers the 
question you have.

>             an inelastic flow "slow down"?

There are codex negotiation/changes that can be done to lower the offered 
load to the network.
But this is not a common practice currently and it depends on the media 
being carried.
We indicated this to allow the codex changes to happen but the flows are 
inelastic in nature.

>             drops.  That is a pretty solid rule.  "Slow down" is not a

This depends on the media being carried.  We will think about how we may 
need to address this.
Currently I am not sure this document should indicate this.

>             But, it still seems a stretch.

We are thinking of a controlled application environment.

>     probing notion seems weak to me.

Thanks for your view point.  We will try to address this.

>             explicitly note that the scheme cannot detect receiver

Thanks for pointing this out.  We will try to clarify this.

>              against end host cheating.]

Yes.  And we will try to clarify this.

>             these are and not mess with them?  I don't follow.

The different ECN encoding used are not predetermined.  We are trying to 
improve this
for our next version of the draft.

>me.  I hope the above comments are somewhat helpful.

Yes, they are and we appreciate any comments you have.
We view all comments from a positive angle and greatly appreciate
your comments on helping us improve the document.
We read this document many times and some of the points may
be clear to us but not clear to others.

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 Aug 2005 14:32:17 -0400

> We are taking the traffic level that start triggering the marking of
> CE to be before any packets start extending the queues handling this
> traffic flow.  This is for real time traffic that does not want the
> queues to build up causing too much delay and jitter.  Hence the
> existing traffic level before the new flow is admitted does not
> exhibit congestion condition.  

Ah - this was not clear.  But, that makes a little sense, I guess.

> There are codex negotiation/changes that can be done to lower the
> offered load to the network.  But this is not a common practice
> currently and it depends on the media being carried.  We indicated
> this to allow the codex changes to happen but the flows are inelastic
> in nature.

Yeah... this is just a massive contradiction I cannot get by - in the
draft or in your response above.  The traffic is inelastic and yet can
somehow change?  I just don't get it.

> This depends on the media being carried.  We will think about how we
> may need to address this.  Currently I am not sure this document
> should indicate this.

Maybe what you need to do is to write some sort of congestion controller
for this sort of traffic and worry about ECN later.  I think that in
order to worry about changing the semantics of ECN one should first have
a control scheme in mind that the IETF can look at and decide whether it
is reasonable for use in the Internet or not.  (That could still be
within a diffserv class and could be much different from TCP friendly,
for sure.)

One of my big hangups here is that I really don't think the document
really gives a good picture of the controller.  And, I think that should
be a requirement here.  I, personally, don't think we need to bless
alternate ECN semantics when we can't understand the controller that it
is feeding into.  (Maybe I am thick here and others do get it.)

> We are thinking of a controlled application environment.

Yeah.  I don't know what that is, but I am skeptical that one can always
assume that.

> The different ECN encoding used are not predetermined.  

Yes, but which segments those encodings are placed on is pretty tightly
defined according to some random process and some seed.  The only thing
it could really detect is an RFC3168 router that wasn't trying to hide
the fact.  If that is the goal, then fine - sketch it and the pros and
cons of the approach (as noted in my previous note).

allman

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 11 Aug 2005 15:05:05 -0400

Mark:
Please see response in line below.
And thank you very much for your further clarification.
-- Kwok --

>somehow change?  I just don't get it.

OK, we will try to clarify this in the next revision (possibly removing 
this point).
Thanks for pointing this out.

>within a diffserv class and could be much different from TCP friendly,

We are thinking of some kind of framework draft that describe the operating
environment.  This should remove the mystery on this.