Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 02:27:03 -0400

Ingemar,

A belated thanks for the feedback. :)

Let me see if I can re-state your points below. First, the per-device
wireless capacity may vary dynamically based on signal quality (with
impacts due to distance, interference), so it may be difficult to assess
how a single subscriber contributes to congestion for a single access
node or base station. Second, with wireless handoffs for mobility, it
may be the case that a subscriber contributes to congestion on one
node/station but not the subsequent one. Is that correct?

Are wireless ISPs selling different bandwidth tiers? Other than
distinguishing 2.5G vs 3G vs 4G service?

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ingemar Johansson S
Sent: Thursday, February 18, 2010 7:55 AM
To: [email-masked]
Subject: Re: [re-ECN] Call for
Comments:draft-livingood-woundy-congestion-mgmt-03

Hi

Thanks for the report. 
I read through it but did perhaps not get all the details. 
As far as I understand it the concept builds upon the fact that users
have a provisioned bandwith, say 10Mbps in e.g the downlink. Once
congetsion sets in the network the congestion manager will enforce some
special treatment on flows that consumes data with a bitrate that is
larger than e.g 80% of their provisioned bandwidth over a given amount
of time. 

The problem I see is that, when I try to transform this concept to
wirless access, is that it is in general difficult to talk about a
provisioned bandwidth for best effort traffic esp. over a multiuser
wireless network with mobility support. The 10Mbs, 1.4Mbs or whatever
figures written in boldface on the boxes are in reality limited by the
laws of physics.
In addition, whatever provisioned bandwidth that one may possibly come
up with is likely to change over time due to changed radio conditions or
handover between different access types. The thing I find attractive
with ConEx is that it has potential to work in these scenarios, the
question is of course if the problem needs a solution like ConEx...

It is possible that I miss some details here, please enlighten me.

Regards
Ingeamr

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 12 Feb 2010 10:38:49 -0500
> From: Jason Livingood <[email-masked]>
> Subject: [re-ECN] Call for Comments:
> 	draft-livingood-woundy-congestion-mgmt-03
> To: <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> This is a call for comments on an individual draft regarding 
> a protocol-agnostic congestion management system, which is 
> related to some of the reason that Conex is starting up.  I 
> and my co-authors would like feedback on the latest revision 
> of this draft at 
> http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03.
> 
> If you have any comments, please send them to me privately 
> for consideration.
> 
> Thank you,
> Jason
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/re-ecn/attachments/20100
> 212/99c6f607/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 12, Issue 24
> **************************************
> 
_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 18 Mar 2010 11:02:27 +0100

Hi

I don't believe wireless ISP's sell different bandwidths at least when it comes to shared access like HSPA or LTE. This depends a little if we are talking GBR* or non-GBR bearers. 
I would belive that we in this group talk mainly about non-GBR bearers which in IETF language translates to Best Effort or DF. As the non-GBR QCIs** have the lowest prio they will yield to GBR traffic, it comes quite natural then that the per-device bandwidth for best effort traffic will then vary dependent on factors such as deployment, coverage, amount of higher priority traffic and number of concurrent users. 

*GBR = Guaranteed Bit Rate, IMS VoIP will typically use a GBR bearer which will strive as mcuh as possible to guarantee a given bitrate, regardless of the conditions, see link below for a more nuanced definition.

**QCI = QoS Class Indentifier 3GPP TS 23.203 table 6.1.7 http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-930.zip

PS.. It is not to me totally clear that ConEx is needed with the above arrangement as the scheduling will likely ensure that devices will share the limited bandwidth pool in a fair way. What ConEx may be helpful with is to make the device aware on the congestion it causes and also to distribute its limited share of bandwidth between flows in the smartest way. We also have the potential issue with DoS (or DDoS) attacks but I am not clear here how ConEx is helpful here.

Regards
Ingemar

> From: Woundy, Richard [mailto:[email-masked]] 
> Sent: den 18 mars 2010 07:27
> To: Ingemar Johansson S; [email-masked]
> Subject: RE: [re-ECN] Call for 
> Let me see if I can re-state your points below. First, the 
> per-device wireless capacity may vary dynamically based on 
> signal quality (with impacts due to distance, interference), 
> so it may be difficult to assess how a single subscriber 
> contributes to congestion for a single access node or base 
> station. Second, with wireless handoffs for mobility, it may 
> be the case that a subscriber contributes to congestion on 
> one node/station but not the subsequent one. Is that correct?
> 
> Are wireless ISPs selling different bandwidth tiers? Other 
> than distinguishing 2.5G vs 3G vs 4G service?
> 
> -- Rich
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
> As far as I understand it the concept builds upon the fact 
> that users have a provisioned bandwith, say 10Mbps in e.g the 
> downlink. Once congetsion sets in the network the congestion 
> manager will enforce some special treatment on flows that 
> consumes data with a bitrate that is larger than e.g 80% of 
> their provisioned bandwidth over a given amount of time. 
> 
> The problem I see is that, when I try to transform this 
> concept to wirless access, is that it is in general difficult 
> to talk about a provisioned bandwidth for best effort traffic 
> esp. over a multiuser wireless network with mobility support. 
> The 10Mbs, 1.4Mbs or whatever figures written in boldface on 
> the boxes are in reality limited by the laws of physics.
> In addition, whatever provisioned bandwidth that one may 
> possibly come up with is likely to change over time due to 
> changed radio conditions or handover between different access 
> types. The thing I find attractive with ConEx is that it has 
> potential to work in these scenarios, the question is of 
> course if the problem needs a solution like ConEx...
> 
> > This is a call for comments on an individual draft regarding a 
> > protocol-agnostic congestion management system, which is related to 
> > some of the reason that Conex is starting up.  I and my co-authors 
> > would like feedback on the latest revision of this draft at 
> > 
> > If you have any comments, please send them to me privately for 
> > consideration.
> > 
> > Thank you,
> > Jason
> > 
> > -------------- next part -------------- An HTML attachment was 
> > scrubbed...
> > URL:

---

From: "Dirk Kutscher" <[email-masked]>
Date: Thu, 25 Mar 2010 17:33:14 +0100

Hi Ingemar,

I agree that from today's perspective on 3GPP's QoS concepts, Conex appears to be mainly relevant for non-GBR (best-effort) traffic. However, considering traffic volume, non-GBR might already by the dominant QoS class (by far).

Moreover, from a different perspective though, congestion exposure (and transport & application layer adaptation) could render strict QoS classes a bit less interesting, so that non-GBR will be the default.

Concerning scheduler-enforced "fair sharing", I am not sure whether this is really the objective, because the whole congestion exposure approach is actually challenging fair sharing.

In summary, I would propose to certainly consider current QoS bearer concept in specific architectures such as LTE/SAE, without constraining the Conex work too much.

Best regards,

Dirk

--
NEC Laboratories Europe

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ingemar Johansson S
> Sent: Thursday, March 18, 2010 11:02 AM
> To: Woundy, Richard; [email-masked]
> Cc: Ingemar Johansson S
> Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-
> congestion-mgmt-03
> 
> Hi
> 
> I don't believe wireless ISP's sell different bandwidths at least when
> it comes to shared access like HSPA or LTE. This depends a little if we
> are talking GBR* or non-GBR bearers.
> I would belive that we in this group talk mainly about non-GBR bearers
> which in IETF language translates to Best Effort or DF. As the non-GBR
> QCIs** have the lowest prio they will yield to GBR traffic, it comes
> quite natural then that the per-device bandwidth for best effort
> traffic will then vary dependent on factors such as deployment,
> coverage, amount of higher priority traffic and number of concurrent
> users.
> 
> *GBR = Guaranteed Bit Rate, IMS VoIP will typically use a GBR bearer
> which will strive as mcuh as possible to guarantee a given bitrate,
> regardless of the conditions, see link below for a more nuanced
> definition.
> 
> **QCI = QoS Class Indentifier 3GPP TS 23.203 table 6.1.7
> http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-930.zip
> 
> PS.. It is not to me totally clear that ConEx is needed with the above
> arrangement as the scheduling will likely ensure that devices will
> share the limited bandwidth pool in a fair way. What ConEx may be
> helpful with is to make the device aware on the congestion it causes
> and also to distribute its limited share of bandwidth between flows in
> the smartest way. We also have the potential issue with DoS (or DDoS)
> attacks but I am not clear here how ConEx is helpful here.
> 
> Regards
> Ingemar
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 25 Mar 2010 17:51:04 +0100

Hi

My personal views, I guess this can be debated quite alot depending on which principle is the best.
I would agree that ConEx is a challenge against scheduler enforced "fair sharing" if one look at it on a short (second by second) time scale. However I for instance see good reasons for a user to halt a large download if e.g the coverage is poor, it is then better to use the available capacity to more prioritized tasks.
Seen from a (large aggregate of users) I would belive that the best total troughput over a longer timescale is acheived if throughput to "hard to reach" users is limited, the simple reason is that these users likely cost a lot in terms of transmission power. If endpoints are made aware of these rules they can themselves prioritize what the temporary thorughput should be used for. I believe that would fit well with the ConEx way of looking at fairness.
Hope I got this clear (translating thoughts from swedish to english is not my stongest asset:-)
  
Regards
Ingemar

> From: Dirk Kutscher [mailto:[email-masked]] 
> Sent: den 25 mars 2010 09:33
> To: Ingemar Johansson S; Woundy, Richard; [email-masked]
> I agree that from today's perspective on 3GPP's QoS concepts, 
> Conex appears to be mainly relevant for non-GBR (best-effort) 
> traffic. However, considering traffic volume, non-GBR might 
> already by the dominant QoS class (by far).
> 
> Moreover, from a different perspective though, congestion 
> exposure (and transport & application layer adaptation) could 
> render strict QoS classes a bit less interesting, so that 
> non-GBR will be the default.
> 
> Concerning scheduler-enforced "fair sharing", I am not sure 
> whether this is really the objective, because the whole 
> congestion exposure approach is actually challenging fair sharing.
> 
> In summary, I would propose to certainly consider current QoS 
> bearer concept in specific architectures such as LTE/SAE, 
> without constraining the Conex work too much.
> 
> Best regards,
> 
> Dirk
> 
> --
> NEC Laboratories Europe
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014
> 
> 
> 
> 
> 
> 
> 
> > it comes to shared access like HSPA or LTE. This depends a 
> little if 
> > we are talking GBR* or non-GBR bearers.
> > > per-device wireless capacity may vary dynamically based on signal 
> > > quality (with impacts due to distance, interference), so 
> it may be 
> > > difficult to assess how a single subscriber contributes to 
> > > congestion for a single access node or base station. Second, with 
> > > wireless handoffs for mobility, it may be the case that a 
> subscriber 
> > > contributes to congestion on one node/station but not the 
> subsequent 
> > > one. Is that correct?
> > >
> > > As far as I understand it the concept builds upon the fact that 
> > > users have a provisioned bandwith, say 10Mbps in e.g the 
> downlink. 
> > > Once congetsion sets in the network the congestion manager will 
> > > enforce some special treatment on flows that consumes data with a 
> > > bitrate that is larger than e.g 80% of their provisioned 
> bandwidth 
> > > over a given amount of time.
> > >
> concept to 
> > > wireless network with mobility support.
> > > The 10Mbs, 1.4Mbs or whatever figures written in boldface on the 
> > > boxes are in reality limited by the laws of physics.
> > > In addition, whatever provisioned bandwidth that one may possibly 
> > > come up with is likely to change over time due to changed radio 
> > > conditions or handover between different access types. 
> The thing I 
> > > find attractive with ConEx is that it has potential to 
> work in these 
> > > scenarios, the question is of course if the problem needs 
> a solution 
> > > like ConEx...
> > >
> --------------------------------------------------------------------
> > > -
> > -
> > > >
> > > > Message: 1
> > > > protocol-agnostic congestion management system, which 
> is related 
> > > > to some of the reason that Conex is starting up.  I and my 
> > > > co-authors would like feedback on the latest revision of this 
> > > > draft at
> > > >
> > >

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 25 Mar 2010 13:17:17 -0400

Hi,

My personal view. The sort of time shifting behavior that a user,
content provider, or delivery mechanism (e.g., P2P) could make use of
exposed congestion feedback are all examples of what I see as an
important goal of Conex.

I recently joined this list and am catching up on the history. However,
I believe Ingemar brings up an important point that "Congestion" is not
only due to queuing, but can be caused by other conditions (e.g.,
changing radio coverage as a mobile device moves about).

Dave 

> Sent: Thursday, March 25, 2010 12:51 PM
> To: Dirk Kutscher; Woundy, Richard; [email-masked]
> Cc: Ingemar Johansson S
> My personal views, I guess this can be debated quite alot 
> depending on which principle is the best.
> I would agree that ConEx is a challenge against scheduler 
> enforced "fair sharing" if one look at it on a short (second 
> by second) time scale. However I for instance see good 
> reasons for a user to halt a large download if e.g the 
> coverage is poor, it is then better to use the available 
> capacity to more prioritized tasks.
> Seen from a (large aggregate of users) I would belive that 
> the best total troughput over a longer timescale is acheived 
> if throughput to "hard to reach" users is limited, the simple 
> reason is that these users likely cost a lot in terms of 
> transmission power. If endpoints are made aware of these 
> rules they can themselves prioritize what the temporary 
> thorughput should be used for. I believe that would fit well 
> with the ConEx way of looking at fairness.
> > I agree that from today's perspective on 3GPP's QoS concepts, Conex 
> > appears to be mainly relevant for non-GBR (best-effort) traffic. 
> > However, considering traffic volume, non-GBR might already by the 
> > dominant QoS class (by far).
> > 
> > Moreover, from a different perspective though, congestion exposure 
> > (and transport & application layer adaptation) could render 
> strict QoS 
> > classes a bit less interesting, so that non-GBR will be the default.
> > 
> > Concerning scheduler-enforced "fair sharing", I am not sure whether 
> > this is really the objective, because the whole congestion exposure 
> > approach is actually challenging fair sharing.
> > 
> > In summary, I would propose to certainly consider current 
> QoS bearer 
> > concept in specific architectures such as LTE/SAE, without 
> > constraining the Conex work too much.
> > 
> > Best regards,
> > 
> > Dirk
> > 
> > --
> > NEC Laboratories Europe
> > 
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL | Registered in England 2832014
> > 
> > 
> > 
> > 
> > 
> > 
> >

---

From: "Dirk Kutscher" <[email-masked]>
Date: Thu, 25 Mar 2010 18:41:32 +0100

Hi Ingemar,

yes, I agree to that. Not sure whether this difference between short and long time scale is really relevant, but the difficult-to-reach user is a good motivation for a different way of resource sharing that is not based on proportional fairness.

It is a different question though whether the topic of how congestion is assessed for certain link layer technology network element is relevant for Conex standardization work -- it may actually be orthogonal.

Best regards,

Dirk

> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: Thursday, March 25, 2010 5:51 PM
> Subject: RE: [re-ECN] Call for Comments:draft-livingood-woundy-
> congestion-mgmt-03
> 
> Hi
> 
> I would agree that ConEx is a challenge against scheduler enforced
> "fair sharing" if one look at it on a short (second by second) time
> scale. However I for instance see good reasons for a user to halt a
> large download if e.g the coverage is poor, it is then better to use
> the available capacity to more prioritized tasks.
> Seen from a (large aggregate of users) I would belive that the best
> total troughput over a longer timescale is acheived if throughput to
> "hard to reach" users is limited, the simple reason is that these users
> likely cost a lot in terms of transmission power. If endpoints are made
> aware of these rules they can themselves prioritize what the temporary
> thorughput should be used for. I believe that would fit well with the
> ConEx way of looking at fairness.
> > > > users have a provisionedbandwith, say 10Mbps in e.g the
> > downlink.

---

From: bo zhou <[email-masked]>
Date: Fri, 26 Mar 2010 01:44:22 +0800

Hi David,

Inline.

> changing radio coverage as a mobile device moves about).

[bo] Support you.
Congestions in mobile network have been investigated in air interface and
mobile backhaul more than in bearer network.

Regards,

Bo Zhou

> > > > > > Message-ID: <[email-masked]<[email-masked]>
> >

-- 
Regards,

Bo Zhou
China Mobile

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Mar 2010 13:59:17 -0400

Mcdysan, David E <[email-masked]> wrote:
> 
> ... "Congestion" is not only due to queuing, but can be caused by
> other conditions (e.g., changing radio coverage as a mobile device
> moves about).

   Though mobility is far from the only "strange" case, it's a good
example of the variety of cases we need to cover.

   For strict re-ecn, it's almost true-by-definition that "congestion"
is whatever ECN marks as "congestion."

   However, that does not mean we can look at one ECN spec and draw
conclusions about what that means in a "roaming" case. Any spec we
write must "just work" if underlying ECN implementations evolve.

   "Changing radio coverage" might actually occur before a queue for
the first radio path fills. And the new path may be well-established
before anyone _could_ tell whether the queue for the first path will
ever clear sufficiently to deliver its packets over the first path.

   Most of these issues are out-of-scope for ConEx. There _will_ be
non-congestion losses, and there will be cases we'd call "congestion"
that never get ECN-marked. And ConEx may well end up with something
quite different from ECN defining what will be marked as congestion.

   Also, wireless mobility cases point out that we can't know how
much hysteresis is in the feedback loop. The ConEx intent is that
senders estimate congestion along the path a packet may take _when_
it travels that path (which by definition must be _after_ the
estimate is made).

   Though re-ecn has laid out an algorithm for such estimates, I
don't believe ConEx intends to rubber-stamp that algorithm. To me,
what particular algorithm a sender uses is out-of-scope for ConEx.
If, for example, a sender knows the receiver is roaming, there
might be an economic case for estimating more congestion than was
seen during the last RTT. (There are a number of other that the
probability of a roaming handover might be inferred.)

--
John Leslie <[email-masked]>

---

From: bo zhou <[email-masked]>
Date: Fri, 26 Mar 2010 02:33:50 +0800

Hi John,

>From your point, the re-ECN only do which can implement "re-ECN" mark in the
transmission path. I am not sure this can bring the End-user the real
congestion information during transmission path.
For example, fixed network implement Ethernet based VPN for its backhaul
transmission or others L2 transmission technologies, which cannot mark
"re-ECN" in my mind. But from real network case, more fixed network
congestion is happened in the backhaul.
Another example is mobile network, only in GI interface the IP packet can be
found. before that, the traffic will go through air-interface,
mobile-backhaul and GTP tunnel, all these parts cannot do "re-ECN" mark as
well. But all these part of missing-"re-ECN" path are major congestion point
in mobile network.

Regards,

Bo Zhou

-- 
Regards,

Bo Zhou
China Mobile

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Mar 2010 14:57:07 -0400

bo zhou <[email-masked]> wrote:
> 
> From your point, the re-ECN only do which can implement "re-ECN" mark
> in the transmission path. I am not sure this can bring the End-user the
> real congestion information during transmission path.

   If you mean that ECN markings are not sufficient information, I tend
to agree.

   However, it may be more important to have a clear definition of
what ConEx marking _means_ than to have it accurately measure any
particular definition of "congestion".

> For example, fixed network implement Ethernet based VPN for its
> backhaul transmission or others L2 transmission technologies, which
> cannot mark "re-ECN" in my mind.

   VPN can be thought of as a tunnel, where "congestion" should be
marked at tunnel ingress. Clearly, the tunnel ingress could ECN-flag
according to a reasonable interpretation of ECN marking.

> But from real network case, more fixed network congestion is happened
> in the backhaul.

   IMHO, it's more important to approximate subpath congestion than to
mark the congestion at any particular point.

> Another example is mobile network, only in GI interface the IP packet
> can be found. before that, the traffic will go through air-interface,
> mobile-backhaul and GTP tunnel, all these parts cannot do "re-ECN" mark
> as well. But all these part of missing-"re-ECN" path are major
> congestion point in mobile network.

   IMHO, ConEx should only specify marking and visibility within IP
packets, not when traffic is carried in some other networking proocol.
This implies that elsewhere we must either estimate congestion outside
of IP forwarding nodes, or settle for only packet loss on congestion.

   To cover one particular case, if IP packets sent by a mobile user
must first travel over a non-IP path, ConEx IMHO cannot handle how to
estimate packet loss before the first IP router, and we'll have to
settle for loss signals. :^(

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 26 Mar 2010 14:53:03 +0000

Bo, John,

I think the 5 points below cover all the concerns in your 2
mails.

There are three types of in-band signal:

* Congestion so far:

a) explicit congestion notification (ECN)

b) implicit congestion notification (drop)

* Whole path congestion:

c) Re-inserted explicit congestion notification (RE)

1) Whenever any segment of the network is congested it tells the
receiver, either by ECN or drop.

2) The source tells the network using RE how much drop *or* ECN is being
seen by the e2e transport (excepting any drop it can be nearly certain is
not due to congestion).

3) The network gives the e2e transport an incentive to warn of
*potential* upcoming congestion (e.g. when rapidly increasing its rate).
If the transport gets this wrong it risks its traffic being briefly
punished for cheating. This makes the source care about the risk to
everyone else's service, because it bears the cost of the risk that its
expectation of congestion is wrong.

4a) A network that wants to check the integrity of the sender's re-ECN
markings has the incentive to ensure it notifies congestion using ECN
rather than drop wherever possible, to make verification much
easier.

4b) ECN is not currently defined for many lower layer technologies
(RFC3168 listed the main ones that will have to be done). Often networks
are designed so that one node (often IP-aware) manages congestion for the
subnet it sends traffic into, to avoid congestion on the non-IP links.

Nonetheless, if such links get congested they will have to drop, but the
operator has an incentive to get ECN standardised for these cases. These
standards will propagate ECN up from the lower layer to IP at the next IP
node (as RFC5129 does for MPLS).

5) The ConEx w-g is chartering to add the RE part to IP (initially
v6).

Standards for ECN part already exist in IP & MPLS.

ConEx is not asking to be chartered to add an ECN-like function to other
lower layer technologies, but ConEx will at least work with drop even
though it is harder to verify. And the ConEx effort will encourage such
standardisation in other bodies (point 4a).

Bob

At 18:33 25/03/2010, bo zhou wrote:

Hi John,

From your point, the re-ECN only do which can implement
"re-ECN" mark in the transmission path. I am not sure this can
bring the End-user the real congestion information during transmission
path.

For example, fixed network implement Ethernet based VPN for its backhaul
transmission or others L2 transmission technologies, which cannot mark
"re-ECN" in my mind. But from real network case, more fixed
network congestion is happened in the backhaul.

Another example is mobile network, only in GI interface the IP packet can
be found. before that, the traffic will go through air-interface,
mobile-backhaul and GTP tunnel, all these parts cannot do
"re-ECN" mark as well. But all these part of
missing-"re-ECN" path are major congestion point in mobile
network.

Regards,

Bo Zhou

On Fri, Mar 26, 2010 at 1:59 AM, John Leslie
<[email-masked]> wrote:

Mcdysan, David E
<[email-masked]
> wrote:

> moves about).

Though mobility is far from the only "strange" case,
it's a good

For strict re-ecn, it's almost true-by-definition that
"congestion"

However, that does not mean we can look at one ECN spec and
draw

conclusions about what that means in a "roaming" case. Any
spec we

write must "just work" if underlying ECN implementations
evolve.

"Changing radio coverage" might actually occur
before a queue for

the first radio path fills. And the new path may be
well-established

before anyone _could_ tell whether the queue for the first path
will

ever clear sufficiently to deliver its packets over the first
path.

Most of these issues are out-of-scope for ConEx. There _will_
be

non-congestion losses, and there will be cases we'd call
"congestion"

that never get ECN-marked. And ConEx may well end up with
something

quite different from ECN defining what will be marked as
congestion.

Also, wireless mobility cases point out that we can't know
how

much hysteresis is in the feedback loop. The ConEx intent is
that

senders estimate congestion along the path a packet may take
_when_

estimate is made).

Though re-ecn has laid out an algorithm for such estimates,
I

don't believe ConEx intends to rubber-stamp that algorithm. To
me,

what particular algorithm a sender uses is out-of-scope for
ConEx.

might be an economic case for estimating more congestion than
was

--

John Leslie
<[email-masked]>

re-ECN mailing list

[email-masked]

--

Regards,

Bo Zhou

China Mobile

re-ECN mailing list

[email-masked]

________________________________________________________________

Bob
Briscoe,
BT Innovate & Design