Subject: [conex] Non-goals and/or misconceptions for conex-concepts-uses

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 00:39:50 +0100

John, and all,

To make this concrete, here's some items I could put in conex-concepts-uses.

Some are non-goals. Some are misconceptions. Not in the sense that 
people are wrong about some objective fact. But in the sense that 
they are wrong about what ConEx is trying to say. Ie. Misconceptions 
about ConEx.

All, = please suggest which ones are most important to keep, which 
ones can go, and which ones need clarifying.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
2.2.  Common Misconceptions about ConEx

    Isn't good provisioning the way to solve congestion, not ConEx?
       This is largely true.  However a statement like this contains a
       number of misconceptions about ConEx:

       *  ConEx is not trying to 'solve' congestion, at least not
          directly.  ConEx is about making congestion visible as a useful
          metric.

       *  Once congestion-based traffic management is in place, the
          operator can set a low congestion threshold to trigger and
          target upgrades to bottlenecks (see Section 5.4).

       *  Removing congestion completely is a non-goal.  If an end-to-end
          transport protocol cannot go fast enough to cause congestion
          somewhere along the path, it is probably broken.  So it is
          misleading to selectively point to parts of a network (e.g. the
          core) that are uncongested by design.  Application performance
          depends on the bottleneck, which a good transport protocol will
          seek out--typically finding it in the access network (or all
          too often in the receiver's buffer, but that's another story).
          Low levels of congestion somewhere are therefore healthy.

       *  Congestion and Utilisation are different.  Protocols like TCP
          aim to fill a link so the transfer finishes as quickly as
          possible.  If a link is 10% utilised on average, this can imply
          it is 100% utilised 10% of the time.  Or it might be 10%
          utilised all the time.  Averaging utilisation over a few
          minutes hides what happened within the averaging time.  In
          contrast, measuring congestion-volume over the same few minutes
          will distinguish between the two cases.

Briscoe & Woundy         Expires January 5, 2012                [Page 7]

Internet-Draft               ConEx Mechanism                   July 2011

       *  It is not our place to judge.  Many operators choose a mix of
          traffic management and capacity upgrades, whether they run a
          University network or a national ISP.  Rather than beating our
          chests about evil traffic management, the idea is to recognise
          it is a legitimate choice, understand why poor practice is
          widespread and enable best practice instead.  At the same time
          providing a good metric to support decisions on upgrading
          bottlenecks too.

    Exposing Congestion to what?  ConEx is about the sender exposing
       congestion to the network, not the other way round.  That would
       not make sense in the context of the TCP/IP protocol suite,
       because the end-systems already detect congestion by design.

    Is the idea for IP routers to use this congestion information?  No
       (but maybe).  The sender puts ConEx information in the IP layer so
       that specific functions can be deployed in the network to use it,
       e.g. traffic management.  These functions might be part of an edge
       IP router, but might also be a separate box.  Some ideas do exist
       for forwarding on routers to optionally use ConEx (e.g. for
       preferential discard), but that is not the current focus.

    Is the idea that network traffic management does congestion control?
       No.  The sender is still expected to do congestion control on fast
       timescales.  The reason the network needs congestion information
       is not for congestion control, but to arbitrate overall fairness
       at run-time.

    But congestion control does fairness, doesn't it?  Not really.
       Congestion control determines the instantaneous shares of some
       bottleneck links (absent network mechanisms like round-robin
       scheduling).  But it doesn't determine how much data an
       application transfers, or how many flows it opens, or which
       congestion control algorithm an application uses, or how many
       applications the user runs, or how many users are active at once.
       These factors all determine how great a share of a link is
       available for any particular data transfer.  Network operators use
       traffic management to ensure some level of overall fairness given
       all these factors.  That's what the congestion information is
       needed for.

    So you want the network to enforce compliance to the TCP algorithm?
       Emphatically no.  Some applications would not work if the network
       forced everything to behave like TCP.  This would also prevent
       deployment of higher performance replacements to TCP.  The idea of
       ConEx is to only enforce overall bulk limits to congestion.  Some
       applications (e.g. short transfers) could be more aggressive than
       TCP.  Others (e.g. long transfers) could be less aggressive,

Briscoe & Woundy         Expires January 5, 2012                [Page 8]

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Michael Menth <[email-masked]>
Date: Thu, 07 Jul 2011 09:53:54 +0200

Hi Bob,

Am 07.07.2011 01:39, schrieb Bob Briscoe:
> people are wrong about some objective fact. But in the sense that they 
> are wrong about what ConEx is trying to say. Ie. Misconceptions about 
> ConEx.
>

I'd put such a section rather at the end or in the appendix of the 
document. Just brief feedback.

... can use congestion information to trigger ...

>          will distinguish between the two cases.
The link to the major point must be better worked out.

>          providing a good metric to support decisions on upgrading
Hm, difficult. Definitely needs rewording.

>       is not for congestion control, but to arbitrate overall fairness
The meaning of the last sentence is not fully clear.

>       all these factors.  That's what the congestion information is
Should be dropped or reformulated.

>       TCP.  Others (e.g. long transfers) could be less aggressive,
Interesting point, good to mention.

Regards,

     Michael

> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 11:06:21 +0100

Michael,

inline tagged [BB]:

At 08:53 07/07/2011, Michael Menth wrote:
>>they are wrong about what ConEx is trying to say. Ie. 
>>Misconceptions about ConEx.
>>

[BB]: If the reader holds one of these misconceptions, they won't 
want to read on. The purpose of putting it here was to make them want 
to read on.

I've discovered Matt Mathis (I think?) wrote a really brief para in 
conex-abstract-mech that says a fair bit of this really succinctly.

"
    There is no expectation that internetwork layer devices will do fine-
    grained congestion control using ConEx information.  That is still
    probably best done at the transport sender.  Rather, the network will
    be able to use ConEx information to do better bulk traffic
    management, which in turn should incentivize end-system transports to
    be more careful about congesting others [I-D.conex-concepts-uses].

"
I will try to emulate this, and cover some of the other bullets too, 
in a couple of similar paras, which would allow the whole doc to flow better:

Two requests for clarification inline...

>The link to the major point must be better worked out.

[BB]: I believe moving the targeted upgrades bullet to last will help 
the logical flow, but I agree this bullet seems disconnected unless 
you think hard about it. It doesn't help the reader make the implicit 
link between provisioning in the major point and utilisation in this bullet.

>Hm, difficult. Definitely needs rewording.

[BB]: The chest-beating part? Or other parts too?

>Should be dropped or reformulated.

[BB]: Many people hold this misconception. I was more pleased with 
this para than any of the others. What's the problem?

>Interesting point, good to mention.

Cheers

Bob

---

From: Michael Menth <[email-masked]>
Date: Thu, 07 Jul 2011 12:17:36 +0200

Hi Bob,

Am 07.07.2011 12:06, schrieb Bob Briscoe:
> [BB]: If the reader holds one of these misconceptions, they won't want 
> to read on. The purpose of putting it here was to make them want to 
> read on.
>
I do not see what this has to do with misconceptions. Essentially it's 
the motivation for conex that was already mentioned in the introduction.

> this para than any of the others. What's the problem?

You probably want to say that congestion control approximates per flow 
fairness but that's not what network operators want. They want 
parameterizable per-user fairness. The former is easy to achieve and 
what we currently have in the Internet. The latter is hard to achieve in 
a flexible way without congestion information. That's why we need conex. 
Right?

Regards,

     Michael

>> <http://www-kn.informatik.uni-tuebingen.de/>
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 12:07:19 +0100

Michael,

At 11:17 07/07/2011, Michael Menth wrote:
>I do not see what this has to do with misconceptions. Essentially 
>it's the motivation for conex that was already mentioned in the introduction.

[BB2]: Good point. It's deleted (actually saved as possible conclusion text).

>You probably want to say that congestion control approximates per 
>flow fairness but that's not what network operators want. They want 
>what we currently have in the Internet. The latter is hard to 
>achieve in a flexible way without congestion information. That's why 
>we need conex.

[BB2]: Now you're making too big a jump for the reader (which I 
usually do and you point out). My proposed text was carrying the 
reader across that jump, to see how different the two are.

>  Right?

[BB2]: Right. And the latter encourages the former to become unequal 
itself (voluntarily and otherwise by force).

Bob

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 13:34:26 +0100

Your suggestions look good. 
Personally would put them later. A good, simple explanation of what conex is about should reduce the chances of a reader being misconceived. You could always put an advert early in the doc

Cong & utilisation - would make this a question in its own right. I'd expand it a bit. Explain how acting assuming it's one (& in fact it's the other) leads to wrong 'cures'.

Network traffic mgt does congestion control? - the bullet could be clearer. TM can be on just as fast timescales as cong control. the "arbitrate overall fairness" point is only one possibility for how TM can use conex info (& the next bullet explains that case)

I'm not sure the first question is quite right, but am not inspired with an alternative at the moment

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: 07 July 2011 08:54
To: Briscoe,RJ,Bob,DES8 R
Cc: ConEx IETF list
Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-uses

Hi Bob,

Regards,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 20:25:39 +0100

Phil & all,

I've decided the question & answer style broke up the flow. So here 
it is re-written in prose and much shorter cos I've cut out chunks 
that weren't really nec (e.g. utilisation != congestion)...

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
2.2.  Non-Goals of ConEx and Common Misconceptions

    Congestion exposure is about the transport sender exposing congestion
    to the network, not the other way round.  That would not make sense
    given by design the transport endpoints handle congestion in the
    TCP/IP protocol suite.

    Nonetheless, it is a non-goal for IP layer devices to use this ConEx
    information to do fine-grained congestion control.  That is still
    best done at the transport sender.  There is also no expectation that
    the information will be used by every IP router and forwarding
    device.  More likely, specific ConEx-based functions like traffic
    management will be added to edge routers.  This in turn should
    incentivize end-system transports to be more careful about congesting
    others.

    Note that good behaviour at individual flow granularity is the
    intended outcome, not the forcing function--it is the end, not the
    means.  Enforcing per-flow compliance to the TCP congestion response
    (or any per-flow rate enforcement) is a non-goal:

    o  It used to be commonly believed that TCP-friendliness was critical
       to fairness on the Internet.  However, a particular congestion
       control algorithm doesn't determine how much data an application
       transfers, or how many flows it opens, or which congestion control
       algorithm an application uses, or how many applications the user
       runs, or how many users are active at once.  These factors all
       have a stronger impact on how great a share of a link is available
       for any particular data transfer.  To achieve fairness at this
       broader granularity (between users, homes, sites or whole
       networks) requires that individual flows in the same bottleneck
       will sometimes be very unequal.

    o  If the network forced everything to be TCP-friendly, some
       important applications would not work.  Worse still, this would
       prevent deployment of higher performance replacements to TCP.  It
       is important to allow give and take between one user's flows: some

       can be more aggressive than TCP and others less, e.g. long
       transfers, following the example of LEDBAT [LEDBAT] (see
       Section 5.2).

    Therefore, network enforcement of per-flow fairness is not only a
    non-goal, it would be a harmful goal in many respects.

    Capacity provisioning in relation to ConEx is another area of
    confusion.  Congestion-based traffic management is not an alternative
    to good capacity provisioning.  Either or both can be good practice
    depending on the situation, and ConEx can provide a useful metric for
    both (see Section 5.4).

    However, removing congestion from _all_ parts of a network is
    unlikely to be a goal.  If an end-to-end transport protocol cannot go
    fast enough to cause congestion somewhere along the path, it is
    probably broken.  A good transport protocol will continue to
    accelerate until it encounters a bottleneck--typically in an access
    network (or all too often in the receiver's buffer, but that's
    another story).  Low levels of congestion _somewhere_ are therefore
    healthy.  Just to be clear though, zero congestion somewhere (e.g. the
    core) is also perfectly healthy.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

At 13:34 07/07/2011, [email-masked] wrote:
>Personally would put them later. A good, simple explanation of what 
>conex is about should reduce the chances of a reader being 
>misconceived. You could always put an advert early in the doc
>
>Cong & utilisation - would make this a question in its own right. 
>I'd expand it a bit. Explain how acting assuming it's one (& in fact 
>it's the other) leads to wrong 'cures'.
>
>Network traffic mgt does congestion control? - the bullet could be 
>clearer. TM can be on just as fast timescales as cong control. the 
>"arbitrate overall fairness" point is only one possibility for how 
>TM can use conex info (& the next bullet explains that case)
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 09 Jul 2011 06:18:19 +0000

Hi Bob,

The text looks good, but I have one comment associated with the following

 >   depending on the situation, and ConEx can provide a useful metric for

Will the features provided Connex apply only to applications that are
using TCP as a transport protocol?
In other words, will the Conex useful metric, mentioned in the paragraph
above, be used by capacity provisioning and congestion-based traffic
management only for applcations that are using TCP as transport protocol
(and not for applications that are using a non-TCP transport protocol)?

If the answer is yes, then please see below:

Consider now that there are applications that use a non-TCP protocol,
e.g., DCCP, that are generating a lot of traffic and are the main causes
of congestion in the network.

Since the capacity provisioning and congestion-based traffic management
will not be able to use the Conex metrics, then the behaviour of the
non-TCP applications that are generating the congestion cannot be
effectively "controled" by using the augmented features provided by
Conex.
In this case for these non-TCP based applications only the current means
of providing congestion control and capacity provisioning can be used.

It might also mean that only the applications that are using TCP as
transport protocol will be effectively "controlled", while they
should'nt.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Sat, 9 Jul 2011 16:14:34 +0100

Conex enables IP nodes to see information about the whole path congestion, so that it is visible as a useful metric; for example to inform the operator's traffic management.

In order to achieve this, the sender signals the information at the transport layer.
The WG is chartered to define this signalling for the TCP transport. It would clearly be possible to also define this signalling for non-TCP transports

phil

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Georgios Karagiannis [[email-masked]]
Sent: 09 July 2011 07:18
To: Briscoe,RJ,Bob,DES8 R
Cc: [email-masked]
Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-uses

Hi Bob,

Best regards,
Georgios

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 9 Jul 2011 21:38:06 +0100

Perhaps a survey of more commonly used transports should be made, with a
investigation if the transport receivers provide "good enough" or
accurate ECN / congestion feedback to the sender...

I.e. DCCP has already more than adequate receiver->sender feedback (the
exact CE "bitstream" can be reconstructed on the sender side, even at a
very low acknowledgement ratio). I'm not really familiar with other
commonly used transports (SCTP, RTP, Reliable Multicast,...) to know
what their feedback mechanism for ECN/congestion looks like. (I believe
RTP recently had the necessary extensions added, to support ECN more
than adequate).

Even if that is strictly speaking out of scope, it may reveal how these
transports fit in with Conex.

Regards,

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]]
> Sent: Samstag, 09. Juli 2011 17:15
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Conex enables IP nodes to see information about the whole path
> congestion, so that it is visible as a useful metric; for example to
> inform the operator's traffic management.
> 
> The WG is chartered to define this signalling for the TCP transport.
It
> would clearly be possible to also define this signalling for non-TCP
> transports
> 
> phil
> 
> From: [email-masked] [[email-masked]] On Behalf Of
> Georgios Karagiannis [[email-masked]]
> Sent: 09 July 2011 07:18
> >    unlikely to be a goal.  If an end-to-end transport protocol
cannot
> go
> >    healthy.  Just to be clear though, zero congestion somewhere
(e.g.
> the

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 09 Jul 2011 20:44:09 +0000

Hi Phil,

Thanks, please see in line!

>In order to achieve this, the sender signals the information at the transport layer.

Georgios: Okay, but in my opinin this should be done for TCP and non-TCP
based applications, see my previous email.

>The WG is chartered to define this signalling for the TCP transport. It would clearly be possible to also define this signalling for non-TCP transports

Georgios: Okay, but does this mean that Conex rechartering is needed in
order to achieve this?

Best regards,
Goergios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 09 Jul 2011 20:49:10 +0000

Hi Richard,

This is a very good suggestion!
If appreciate I could work on such an activity!

Best regards,
Georgios

---

From: <[email-masked]>
Date: Mon, 11 Jul 2011 09:21:37 +0100

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 09 July 2011 21:44
To: Eardley,PL,Philip,DES8 R; Briscoe,RJ,Bob,DES8 R
Cc: [email-masked]
Subject: RE: [conex] Non-goals and/or misconceptions for conex-concepts-uses

Hi Phil,

[phil] Yes. 
I think the activity Richard suggests could be valuable, but it is outside the charter as I read it. i remember there was a discussion during chartering and it was decided to restrict to TCP, since this represents the bulk of the traffic.
phil

Best regards,
Goergios

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 11 Jul 2011 09:35:17 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: 11 July 2011 09:22
> It would clearly be possible to also define this signalling for non-TCP
> transports
> 
> I think the activity Richard suggests could be valuable, but it is
> outside the charter as I read it. i remember there was a discussion
> during chartering and it was decided to restrict to TCP, since this
> represents the bulk of the traffic.

{TM} I think the restriction was also imposed to try and ensure the WG gets
something out the door quickly. As I remember the idea was that TCP would
then provide the canonical example and other transports would then be added
afterwards.

Having said that there is nothing stopping Georgios or Richard from trying
to conduct a survey of that sort as it will (hopefully) be useful in the
future.

Toby

> cannot go
> (e.g. the

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 11 Jul 2011 15:17:44 +0000

Hi Toby, Hi Phil,

Thanks for the information!

Maybe is good to have a f2f discussion in Quebec about this topic!

I am very much ineterested in working on it!

Best regards,
Georgios

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Jul 2011 17:50:05 +0100

Phil, Georgios,

At 16:14 09/07/2011, [email-masked] wrote:
>It would clearly be possible to also define this signalling for 
>non-TCP transports

... and in our original re-ECN drafts we gave guidelines on how to do 
this for DCCP, SCTP, NSIS/RSVP and the various main styles of UDP 
transport - it really isn't difficult.

<http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09#section-6.2>

Bob

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 13 Jul 2011 17:13:58 +0000

Hi Bob,

Section 6.2 gives guidelines on which changes (e.g.,add an additional ECC
object) need to be done in the existing non-TCP transport protocols.

It is important to investigate whether there are ways of using these
non-TCP protocols without requiring any protocol changes to them
(requiring to add an object)!

Best regards,
Georgios