Subject: [conex] What is a normal ECN rate ?

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 22 Jun 2010 13:14:24 +0200

Hi

Seeking advice on a subject that I don't fully understand...

The idea with conex is that the ECN-CE markings should be re-inserted into the IP header in the forward flow for future use by e.g policers. This I believe will require that there is some kind of uniform behavior in ECN marking algorithms or?
If not there is a chance that different nodes in the mesh may ECN-CE mark differently for the same load (in an abstract meaning) as there are AFAIK no strict guidelines besides "mark instead of drop", and this may make policing throublesome.
 
Trying to formulate a proper question here: Is the goal of ECN-CE marking that the ECN rate should be zero at "normal congestion" or can one imagine the case that e.g a realtime streaming service can tune its bitrate such that the ECN rate should stay below for instance 2% where 2% ECN rate is in fact considered a healthy condition?.

Regards
Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: Fred Baker <[email-masked]>
Date: Tue, 22 Jun 2010 14:32:45 +0200

comparable to nominal loss rates in TCP

On Jun 22, 2010, at 1:14 PM, Ingemar Johansson S wrote:

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

http://www.ipinc.net/IPv4.GIF

---

From: John Leslie <[email-masked]>
Date: Tue, 22 Jun 2010 09:11:11 -0400

Ingemar Johansson raised a question, which brought to mind an issue
documented in the NomCom report:

http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00#section-7.3
] 
] Several individuals in the community emphasized the importance of
] having a researcher in the Transport AD position, given that the
] primary focus of current efforts is research based.  However, none of
] the individuals with that specific background or focus were able to
] accept the nomination...

   (I am neither a researcher nor interested in that AD position; but
I do perhaps have a Transport-101 level of understanding. I think it's
important to develop folks that _can_ fill that position: so I'll start
this thread and see what happens...)

Ingemar Johansson S <[email-masked]> wrote:
> 
> The idea with conex is that the ECN-CE markings should be re-inserted
> into the IP header in the forward flow for future use by e.g policers.
> This I believe will require that there is some kind of uniform behavior
> in ECN marking algorithms or?

   Good question!

   Strangely enough, the answer is, "No."

   Let me start with the legacy "pure-dumb" forwarding router:

- for every outgoing interface, have a buffer of "convenient" size;
- when a packet to forward won't fit in it, drop that packet.

"Convenient size" was left completely open.

   Transport protocols, especially TCP, were initially designed around
this pure-dumb forwarding approach. They had to come up with algorithms
to "accurately guess" when a packet had been dropped. (The student would
do well to research some of these.)

   Since our "pure-dumb" forwarding network explicitly _does_not_
guarantee in-order delivery, the presence of an out-of-order packet
cannot be taken as a definitive indication of a dropped packet. It
turns out that different flavors of TCP congestion control use
different indicators of dropped packets, but none of them can detect
the loss in as little as one Round-Trip-Time (RTT).

   Explicit Congestion Notification attempts to close this loop faster.
The basic change proposed by ECN is to detect the impending need to
drop a packet; and instead "mark" a packet already in the queue as
"we're congested here: please slow down."

   That signal (hopefully) will reach the sender in one RTT.

   While ECN states how the sender should react, it really has no way
of enforcing that; and everybody involved knows that there are different
flavors of TCP congestion control. Thus it's pretty loose what will
actually happen.

   This is a problem for ECN deployment, of course. Folks are hesitant
to program their routers to go to all this trouble if they can't trust
senders to actually back off. Worse yet, there may be routers along the
remainder of the path that strip off ECN marks. :^(

   (This turns out to be a deployment issue for ConEx, too.)

   Getting back to Ingemar's question: the important function of ECN
is to get feedback sooner; and the router that ECN-marks a packet _is_
congested (in the sense that it's already pushing its limit of delay
in forwarding, and "expects" to need to drop packets). Thus backing
off the sending rate clearly is appropriate.

   Backing off sooner is an unmitigated good. Packet loss does nasty
things. In particular, it prevents all ordinary TCP algorithms from
ever filling a pipe if the Bandwidth-Delay product is too large.

> If not there is a chance that different nodes in the mesh may ECN-CE
> mark differently for the same load (in an abstract meaning) as there
> are AFAIK no strict guidelines besides "mark instead of drop", and
> this may make policing throublesome.

   Ingemar is correct that there are no strict guidelines.

   But in a well-functioning network we can hope for only one router
along the path needing to ECN mark an individual packet, and we do
know that router has good reason for the sender to slow down.

   "Policing" is a ConEx thing, not an ECN thing. Many details will
need to be worked out (and aren't even in-charter for us yet), but
the essence of proposals we've seen so far is that policing will
verify that the sender isn't exceeding an allowance (or has sufficent
credit if the business model involve charging).

   Thus, policing is not tied to any particular algorithm for ECN
marking.

> Trying to formulate a proper question here: Is the goal of ECN-CE
> marking that the ECN rate should be zero at "normal congestion"

   Yes. (Of course, "normal congestion" here is taken to mean no
packets being dropped, at a minimum.)

> or can one imagine the case that e.g. a realtime streaming service
> can tune its bitrate such that the ECN rate should stay below for
> instance 2% where 2% ECN rate is in fact considered a healthy
> condition?.

   IMHO, a 2% marking rate can _never_ be considered a healthy
condition. I think the most wildly optimistic "healthy condition"
any ISP today would consider is closer to 0.5% -- and that's bad
enough to prevent filling pipes today.

   But, to answer the literal question, a streaming service that has
sufficient credit _could_ tune to 2% marking in order to monopolize
the congested link -- and the money changing hands could (in a perfect
world) go towards expanding the capacity of that link.

   (In the real world, I'd guess that the money changing hands would
have to be "sufficient" to cover that cost or there'd be _serious_
pressure on the upstream ISP to mark less packets.)

--
John Leslie <[email-masked]>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 22 Jun 2010 10:03:07 -0400

Hi John,

I found your answer very helpful in understanding the goals of conex.

You got distracted by the sample numbers used in the last question,
and I think you didn't answer the question. I think I know the answer,
but let me restate the question with a different threshold to prompt
your answer ...

> > or can one imagine the case that e.g. a realtime streaming 
> service can 
> > tune its bitrate such that the ECN rate should stay below 
> for instance 
> > 0.4% where 0,4% ECN rate is in fact considered a healthy
condition?.

dbh

---

From: John Leslie <[email-masked]>
Date: Tue, 22 Jun 2010 10:26:59 -0400

David Harrington <[email-masked]> wrote:
>>> or can one imagine the case that e.g. a realtime streaming service can 
>>> tune its bitrate such that the ECN rate should stay below for instance 
>>> 0.4% where 0,4% ECN rate is in fact considered a healthy condition?.

   That's still a little high for me, but if you'll permit me to revise
it yet again, to 0.1%, I believe we consider it reasonable to tune the
conex-CongestionExpected markings to 0.1% -- in today's Internet.

   Of course, that must somehow interact with whatever business model
the ISP sets up... but I believe we envision allowance-based models
where such a marking rate would be "reasonable."

   (When you quadruple that, the interaction becomes more critical,
though I wouldn't _necessarily_ consider 0.4% unreasonable in all cases.)

   Getting back to didactic mode...

   The "transport" issue here is how to fill the pipe for a "normal"
case. Neither ECN nor CONEX can get us all the way there, as currently
envisioned. To the extent that a transport algorithm actually backs off
50% upon an ECN mark, you will need to work out the Bandwidth-Delay
product to find an ECN-marking rate that permits filling the pipe.

   The conex-marking rate _can_ exceed that ECN-marking rate without
preventing you from filling the pipe, but you probably don't want to
exceed it by much, because conex-marking literally invites ECN-marking
to catch up with it.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Jun 2010 16:40:02 +0100

David,

There's a simpler answer to Ingemar's question I think...

 > in ECN marking algorithms or?

Policing is only concerned with average/equilibrium congestion levels 
(whether 0.1% or 0.05% or 0.5%). An AQM algo has has little if any 
bearing on the equilibrium congestion level. So no uniform AQM 
behaviour is needed.

Average/equilibrium congestion levels depend primarily on the 
algorithms in the end-systems that are driving load against the 
congestion. As long as at some point the AQM gives a large increase 
in drop/marking for a tiny increase in load (a hockeystick curve), 
the end-systems will find the equilibrium point where their combined 
pushing is no longer enough to push any higher up the hockeystick. If 
they want to push higher up the hockeystick, no amount of algorithm 
design in the queue can make the congestion level lower.

As long as the queue gives you more drop or marking for a longer 
*queue*, congestion indications will be convex (ie hockeystick) with 
*load*. Any queue will do that, with or without active queue management (AQM).

Nonetheless, an AQM does have to be designed carefully to maintain 
stability, responsiveness and randomness (ie no bias against certain 
packets). But its design can hardly affect the equilibrium at all.

Bob

>exceed it by much, because conex-marking literally invites ECN-marking

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Steve Bauer <[email-masked]>
Date: Tue, 22 Jun 2010 12:22:00 -0400

> exceed it by much, because conex-marking literally invites ECN-marking

Perhaps I am missing your point here... in what sense would
conex-marking at a rate higher than the actual ECN-marking rate create
this incentive?    How could any one provider along the path (except
the last hop provider) recognize such a scenario as the conex-marking
rate will always naturally exceed the ECN-marking before the
congestion point.

Thanks,
Steve

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 22 Jun 2010 21:58:10 +0200

Hi

Thanks all for taking the time to answer my question. My interpretation of this is that for general internet 0.1 to 0.5% are reasonable figures. 

On the other hand one can perhaps for some dedicated QoS traffic envision a higher "equilibrium rate" ?. If one take that video streaming case again one can think of a rate control that acts according to a function of the ECN rate [ bitrate=f(ECN_rate) ] or something similar. My take is that it should be easier to get a smoothly varying bitrate depending on the congetsion situation if the concestion events occur at a higher frequency. With a 0.1% equilibrium point the video streaming service will likely have to resort to TCP like behavior (rate halving) in its response to the ECN marks. 

/Ingemar

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 22 juni 2010 17:40
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [conex] Transport 101
> 
> David,
> 
>  > The idea with conex is that the ECN-CE markings should be 
> re-inserted  > into the IP header in the forward flow for 
> future use by e.g policers.
>  > This I believe will require that there is some kind of 
> uniform behavior  > in ECN marking algorithms or?
> 
> Policing is only concerned with average/equilibrium 
> congestion levels (whether 0.1% or 0.05% or 0.5%). An AQM 
> algo has has little if any bearing on the equilibrium 
> congestion level. So no uniform AQM behaviour is needed.
> 
> algorithms in the end-systems that are driving load against 
> the congestion. As long as at some point the AQM gives a 
> large increase in drop/marking for a tiny increase in load (a 
> hockeystick curve), the end-systems will find the equilibrium 
> point where their combined pushing is no longer enough to 
> push any higher up the hockeystick. If they want to push 
> higher up the hockeystick, no amount of algorithm design in 
> the queue can make the congestion level lower.
> 
> As long as the queue gives you more drop or marking for a 
> longer *queue*, congestion indications will be convex (ie 
> hockeystick) with *load*. Any queue will do that, with or 
> without active queue management (AQM).
> 
> Nonetheless, an AQM does have to be designed carefully to 
> maintain stability, responsiveness and randomness (ie no bias 
> against certain packets). But its design can hardly affect 
> the equilibrium at all.
> 
> 
> Bob
> 
> > > and I think you didn't answer the question. I think I know the 
> > > answer, but let me restate the question with a different 
> threshold 
> > > to prompt your answer ...
> > >
> > >>> instance 0.4% where 0,4% ECN rate is in fact considered 
> a healthy condition?.
> >
> >    That's still a little high for me, but if you'll permit me to 
> >revise it yet again, to 0.1%, I believe we consider it reasonable to 
> >tune the conex-CongestionExpected markings to 0.1% -- in 
> today's Internet.
> >

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Jun 2010 09:40:29 -0400

Steve Bauer <[email-masked]> wrote:
> this incentive?

   I apologize if I gave the impression that a higher-than necessary
CONEX marking rate (Congestion Expected) will cause the ECN marking
rate (Congestion Experienced) to rise to meet it. That is not what I
intended to say. :^(

   CONEX marking (Congestion Expected) _does_ invite ECN marking
(Congestion Experienced) in that the CONEX mark does say, "Please mark
Congestion-Experienced and forward if the alternative seems to be
dropping a packet," but I wouldn't expect that invitation to be
accepted as much as 1% of the time.

> How could any one provider along the path (except the last hop
> provider) recognize such a scenario as the conex-marking rate will
> always naturally exceed the ECN-marking before the congestion point.

   Steve is right. My wording was poor. My bad.

   BTW, Bob Briscoe gave a much better explanation of why higher-than-
needed CONEX-marking doesn't pay.

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Jun 2010 10:09:28 -0400

Ingemar Johansson S <[email-masked]> wrote:
> 
> Thanks all for taking the time to answer my question. My interpretation
> of this is that for general internet 0.1 to 0.5% are reasonable figures. 

   I won't disagree (though I still think 0.5% is high).

> On the other hand one can perhaps for some dedicated QoS traffic
> envision a higher "equilibrium rate" ?. If one takes that video
> streaming case again one can think of a rate control that acts
> according to a function of the ECN rate [ bitrate=f(ECN_rate) ] or
> something similar.

   This (IMHO) is clearly outside our charter; but traffic is low enough
at the moment that I think we can elaborate a bit before deciding where
this discussion belongs.

> My take is that it should be easier to get a smoothly varying bitrate
> depending on the congestion situation if the congestion events occur
> at a higher frequency.

   Fundamentally, to get smoother variation, the reduction signaled by
an individual ECN-CE mark would need to be less than 50%. This, IMHO,
would indeed be reasonable if we agreed somehow to create more of them.
(Unfortunately, setting more CONEX-CE marks isn't likely to cause this,
despite my poorly-worded earlier posting.)

> With a 0.1% equilibrium point the video streaming service will likely
> have to resort to TCP like behavior (rate halving) in its response
> to the ECN marks. 

   Unfortunately, the basic ECN expectation in RFC 3168 is that an
ECN-CE mark will cause rate halving.

   I'm sure Bob Briscoe can answer better than I as to how this rate-
halving could be relaxed: I see several possibilities, but they seem
to require changes in RFC 3168, and that goes way beyond our charter.

   Nonetheless, our charter calling for implementation in IPv6, it
seems quite reasonable that IPv6 ECN-marking might not need to be
limited to the two bits or might be extended somehow to better
accomodate gentler variations in bit-rate.

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Jun 2010 16:41:19 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John Leslie
> Sent: 23 June 2010 15:09
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: [conex] Off-Topic: Smoothing Variations in BitRate
> 

I think for this discussion we need to clarify exactly what our network
model is. As I see it there are 3 main models: mobile broadband which I
choose to believe is out of charter, DSL or cable

In DSL the traffic is heavily aggregated at the DSLAM and then several
DSLAMs will dump their traffic onto IP at a B-RAS. I can easily believe
congestion at the B-RAS exceeds 0.5% at certain times, at least
occasionally.

In Cable things may be different, I am not really qualified to comment on
it...

> at the moment that I think we can elaborate a bit before deciding where

I agree - out of charter, but no harm in discussing it here

> despite my poorly-worded earlier posting.)

I think Ingemar would be well advised to talk to Matt Mathis and Bob Briscoe
here... I think this is related to the question of whether the congestion
controller responds to p or sqrt(p) (where p is the congestion on the path)

> ECN-CE mark will cause rate halving.

Quoting it: 
"  Upon the receipt by an ECN-Capable transport of a single CE packet,    
   the congestion control algorithms followed at the end-systems MUST be
   essentially the same as the congestion control response to a *single*
   dropped packet."
> to require changes in RFC 3168, and that goes way beyond our charter.

This is an issue of transport vs network layers. ECN is at the network layer
(as is conex). The appropriate response at the transport layer depends on
that transport. If you are a real-time inelastic transport, clearly the
response is different than if you were a scavenging transport or an elastic
bulk data transport...

Conex is essentially transport-agnostic and I thought the idea is to try and
get the whole network to move on from its inherent assumption that
everything uses TCP. As long as the network can see how much congestion a
flow is causing then that flow can respond as it wants. If it is causing too
much congestion then it runs the risk of being policed in some manner...

> accomodate gentler variations in bit-rate.

Indeed it would be silly to limit it to 2 bits if there is space for more
without increasing the overhead. This is potentially a very rich vein for
discussions in its own right, independent of this current discussion

Toby

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Jun 2010 16:56:33 +0100

OK, not sure if this is going to help at all, but let's give it a try!

Everyone in this discussion is assuming some variant of conex that looks
more than a little like Bob's re-ECN. When you mark conex markings (let's
call them congestion expected to mirror congestion experienced), you are
telling the network how bad you think downstream congestion is currently. If
you are starting a flow (or changing rate rapidly for some other purpose)
then you are not sure how bad congestion is because your own flow is likely
to have a measurable impact on it. Consequently a sensible sender will
slightly inflate the congestion expected signal to allow for this
possibility.

I think John was suggesting that such behaviour may result in the ECN
marking rate appearing fractionally lower than the congestion-expected rate.

Implicitly conex marking implies ECN capability and that automatically
encourages a router to mark if it is ECN capable. This is an orthogonal
issue (as are all the related issues Bob and Matt were discussing in their
email exchange relating to conex on drop as distinct from conex on ECN mark)

If a sender consistently indicates too high a rate for congestion expected
then this does have consequences for how congestion can be tracked in the
network. In particular it can make a network in the middle look as though it
is being asked to forward more congestion-causing traffic than it actually
is.

> Sent: 23 June 2010 14:40
> To: Steve Bauer

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Jun 2010 17:12:24 +0100

Ingemar,

The 'normal' congestion level depends on how the end-system 
congestion control algos scale with bit-rate. See Matt Mathis and my 
joint presentation to ICCRG co-located with last IETF in Anaheim:
<http://www.ietf.org/proceedings/77/slides/iccrg-11.pdf>

Slide 5: For example, if most endpoints are TCP Reno in Congestion 
Avoidance phase, and as the average window increases over the years 
(assuming capacity increases), the loss fraction will reduce over the 
years O(1/w^2), where w is the average window.

BTW, the loss *rate* [loss per time] as opposed to loss fraction [% 
loss per packet] will decrease O(1/w).
Example:
   1Mb/s => 8.3pkt window => 2%      loss fraction => 1.67   loss/sec
  10Mb/s => 83pkt  window => 0.02%   loss fraction => 0.167  loss/sec
100Mb/s => 830pkt window => 0.0002% loss fraction => 0.0167 loss/sec

BUT!!!...

Slide 6: If the rate of flow arrivals stays constant, but bit-rates 
increase as in the example above, slow start (SS) will increasingly 
dominate over congestion avoidance (CA) as the source of congestion.

Example: if on average you get 0.1 flow/sec arriving at the 
bottleneck (say), then slow start overshoot will cause 0.1 loss 
events per sec.
Comparing this SS loss frequency with the CA loss frequency above, as 
average flow rate rises:
   1Mb/s => CA: 1.67   loss/sec; SS: 0.1 loss event/sec
  10Mb/s => CA: 0.167  loss/sec; SS: 0.1 loss event/sec
100Mb/s => CA: 0.0167 loss/sec; SS: 0.1 loss event/sec

So as bit-rates increase 100x, CA losses evolve from being 17x more 
frequent that SS loss events to being nearly 6x less frequent than 
SS. In addition, the number of packets lost in an SS loss event goes 
up linearly with flow rate, whereas CA losses are generally single packets.

This is all part of the argument that we need to move to scalable 
congestion control (slide 8). In the classic TCP Reno CA fomula, the 
window scales with 1/sqrt(p). With a scalable congestion control it 
scales with 1/p.

Rearranging the formulae the other way up, with scalable congestion 
controls, the loss fraction [%] scales with O(1/w) not O(1/w^2) like 
TCP Reno does. Then loss rate [loss/sec] stays constant over time as 
bit rates increase. This keeps the frequency of the control signal 
constant, which is what you were looking for in your video streaming example.

That's actually another dimension to the motivations for ConEx. I 
don't normally bother motivating ConEx this way, because it's too 
hard to explain to newbies (the other motivations are easy to explain??!!).

There doesn't seem to be a way to manage the transition from 
unscalable TCP Reno to scalable congestion controls unless we have 
something that allows their relative impact on others to be compared. 
ConEx does this, whereas the TCP-friendly paradigm would just rule 
scalable congestion controls out of order.

Here's some links to scalable (aka Proportionally Fair or PF) 
congestion controls:
<http://www.bobbriscoe.net/projects/refb/#Weighted_andor_Proportionally_Fair>
Note only some of the list are PF (DCTCP, Relentless, STCP, Weighted 
Window CC).

HTH

Bob

At 20:58 22/06/2010, Ingemar Johansson S wrote:
>Hi
>
>Thanks all for taking the time to answer my question. My 
>interpretation of this is that for general internet 0.1 to 0.5% are 
>reasonable figures.
>
>envision a higher "equilibrium rate" ?. If one take that video 
>something similar. My take is that it should be easier to get a 
>smoothly varying bitrate depending on the congetsion situation if 
>the concestion events occur at a higher frequency. With a 0.1% 
>equilibrium point the video streaming service will likely have to 
>resort to TCP like behavior (rate halving) in its response to the ECN marks.
>
>/Ingemar
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Jun 2010 18:20:33 +0100

John,

MY previous mail on the Transport 101 thread ended up saying how one 
motivation for ConEx is to enable a shift to scalable congestion 
controls away from TCP Reno (see the mail for details)...

Many of these more modern controls are not anything like as jumpy as 
Reno, at least in the downward direction. For instance, Relentless 
only reduces the window by one packet for each packet lost/marked.

The hard part is the upward direction, particularly slow start and 
the increase during congestion avoidance phase of controls like 
Cubic. TCP RAPID (Infocom'09) is an interesting new approach in this 
respect, altho it looks like plenty more work is needed on practicality.

Zooming out from the details of various proposed congestion controls, 
the relevant point for this list is that, if a network counts 
congestion-volume against you, you have an incentive to use a 
congestion control that doesn't spike into the  traffic of others, at 
least not more than you need it to in order to achieve your 
performance objective.

Bob

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 23 Jun 2010 20:15:55 +0200

Hi

Some comments [IJ] inline below

Will be away on vacation until the week before IETF-78 will likely not respond to emails until then.

Regards and thanks again for the help.
Ingemar
________________________________________
Från: John Leslie [[email-masked]]
Skickat: den 23 juni 2010 16:09
Till: Ingemar Johansson S
Kopia: Bob Briscoe; [email-masked]
Ämne: Off-Topic: Smoothing Variations in BitRate

[IJ] Ok

   This (IMHO) is clearly outside our charter; but traffic is low enough
at the moment that I think we can elaborate a bit before deciding where
this discussion belongs.
[IJ] I would too believe that it is is getting outside the charter for this WG. Looking in perspective I should perhaps have posted this to TSVWG instead, not sure however that  I would have received the same response.

   Unfortunately, the basic ECN expectation in RFC 3168 is that an
ECN-CE mark will cause rate halving.
[IJ], Yes I understand this. On the other hand protocols like DCTCP (http://research.microsoft.com/apps/pubs/?id=121386) goes somewhat inbetween.

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 23 Jun 2010 20:28:54 +0200

Hi

Comments inline below.

Regards
Ingemar
________________________________________
Från: Toby Moncaster [[email-masked]]
Skickat: den 23 juni 2010 17:41
Till: 'John Leslie'; Ingemar Johansson S
Kopia: [email-masked]
Ämne: RE: [conex] Off-Topic: Smoothing Variations in BitRate

> interpretation

I think for this discussion we need to clarify exactly what our network
model is. As I see it there are 3 main models: mobile broadband which I
choose to believe is out of charter, DSL or cable
[IJ] I believe that it would be unfortunate to exclude mobile broadband. I would believe that wireless access e.g LTE can already provide with a decent  fairness mechanisms as each users gets its own queue. The wireless access is however part of the ECN loop and will therefore affect the performance of ConEx. 

I think Ingemar would be well advised to talk to Matt Mathis and Bob Briscoe
here... I think this is related to the question of whether the congestion
controller responds to p or sqrt(p) (where p is the congestion on the path)
[IJ] Understood. Need to do some additional homework here after my vacation.

Quoting it:

Toby

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Jun 2010 19:57:16 +0100

Ingemar,

I would strongly agree with you that mobile bb is 
not outside the charter. Nothing in the charter says ConEx is non-mobile.

We are meant to believe in "IP over everything...."

Similarly, I strongly agree with Toby that ConEx 
should not be about TCP only (the rate halving is 
just one of many possible responses).

"...and everything over IP."

Cheers

Bob

At 19:28 23/06/2010, Ingemar Johansson S wrote:
>[IJ] I believe that it would be unfortunate to 
>exclude mobile broadband. I would believe that 
>wireless access e.g LTE can already provide with 
>a decent  fairness mechanisms as each users gets 
>its own queue. The wireless access is however 
>part of the ECN loop and will therefore affect the performance of ConEx.
>

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 26 Jun 2010 14:28:16 +0100

If we are going to include mobile BB then we need to encourage guys from the
mobility area to get involved...

Toby 

> Sent: 25 June 2010 19:57
> Cc: Toby Moncaster; 'John Leslie'; [email-masked]
> Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate
> 
> Ingemar,
>

---

From: Zhu Lei <[email-masked]>
Date: Mon, 28 Jun 2010 09:42:38 +0800

Hi all,

I personally did not see the harms from collecting participants of IP mobility into congestion control.

But, congestion control did not impact the IP mobility issues by now. And, I think this would be ok to mark ECN indication in IP header without involving IP mobility.

If your "mobility" means the particular topics at access part of networks, I may close the mouth before really getting it.

Zhu Lei
HUAWEI TECHNOLOGIES CO.,LTD.  huawei_logo

Address: Huawei Bld, Xinxi Rd
Shangdi Information Indursty BaseHaidian District
Beijing 100085, P.R.China
Tel: 86-10-82836301
Fax: 86-10-82836920
Mobile: 86-13910157020
E-mail: [email-masked]
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Toby Moncaster
发送时间: 2010年6月26日 21:28
收件人: 'Bob Briscoe'; 'Ingemar Johansson S'
抄送: [email-masked]
主题: Re: [conex] Off-Topic: Smoothing Variations in BitRate

If we are going to include mobile BB then we need to encourage guys from the mobility area to get involved...

Toby 

> I would strongly agree with you that mobile bb is not outside the 
> charter. Nothing in the charter says ConEx is non- mobile.
> 
> Similarly, I strongly agree with Toby that ConEx should not be about 
> TCP only (the rate halving is just one of many possible responses).
> 
> >choose to believe is out of charter, DSL or cable [IJ] I believe that 
> >it would be unfortunate to exclude mobile broadband. I would believe 
> >that wireless access e.g LTE can already provide with a decent  
> >fairness mechanisms as each users gets its own queue. The wireless 
> >access is however part of the ECN loop and will therefore affect the 
> >performance of
> ConEx.
> >
> >In DSL the traffic is heavily aggregated at the DSLAM and then 
> >several DSLAMs will dump their traffic onto IP at a B-RAS. I can 
> >easily
> believe
> >In Cable things may be different, I am not really qualified to 
> >comment
> on
> >it...
> >
> > >
> > >    This (IMHO) is clearly outside our charter; but traffic is low 
> > > enough at the moment that I think we can elaborate a bit before 
> > > deciding
> where
> > > this discussion belongs.
> >
> > >    Fundamentally, to get smoother variation, the reduction 
> > > signaled
> by
> >    the congestion control algorithms followed at the end-systems 
> >MUST
> be
> >This is an issue of transport vs network layers. ECN is at the 
> >network
> layer
> >(as is conex). The appropriate response at the transport layer 
> >depends
> on

---

From: Kevin Mason <[email-masked]>
Date: Mon, 28 Jun 2010 18:47:58 +1200

Whilst involvement for as wide an industry is potentially valuable, I do not think it is essential at this juncture.

Exposing congestion information to the network is only of benefit if practical policy decision and enforcement points can receive/extract it, and then apply policy as required at the appropriate points in response.

So this policy point needs to be "user" aware. In most cass the user for network service is only down to the account holder (UNI for BBF access and UA for 3GPP mobility access)

For access networks, the key policy management point is the BRAS/BNG (for BBF fixed architectures) and the GGSN (for 3GPP mobile access) fro downstream traffic (toward the user) and the Routing gateway (BBF) or nodeB under control of the RAN (3GPP mobile) upstream.

For broadband forum architecture both the BNG and the RG are primarily IP devices, so congestion information conveyed in the IP header could realistically be extracted.

For mobility the GGSN is an IP device but the RAN/NodeB does not inspect the IP header (as I understand) as the IP is encapsulated at this point.

So the key thing is not toget to worries about how particular architecture may use it, but ensure the relevant information can be inspected/extracted at a network policy management point (like a BRAS or GGSN), and generically how this might be acted on or conveyed to an appropriate and effective enforcement point.

Cheers
Kevin Mason

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Toby Moncaster
Sent: Sunday, 27 June 2010 1:28 a.m.
To: 'Bob Briscoe'; 'Ingemar Johansson S'
Cc: [email-masked]
Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate

Toby 

> > > enough

---

From: "Dirk Kutscher" <[email-masked]>
Date: Mon, 28 Jun 2010 11:48:21 +0200

I also interpreted the charter to include mobile bb -- which is IMO good.

Best regards,

Dirk

> Of Toby Moncaster
> Sent: Saturday, June 26, 2010 3:28 PM
> > >model is. As I see it there are 3 main models: mobile broadband
> which
> > I
> several
> > >controller responds to p or sqrt(p) (where p is the congestion on
> the
> > path)
> > >without increasing the overhead. This is potentially a very rich
> vein
> > for