Subject: [conex] Mobile Communication Congestion Exposure Scenario

From: Dirk Kutscher <[email-masked]>
Date: Tue, 8 Mar 2011 12:27:14 +0000

Hi all,

We have started a draft on describing how CONEX could be useful in mobile communication networks such as LTE:

https://datatracker.ietf.org/doc/draft-kutscher-conex-mobile/

The text currently describes how the CONEX uses cases (from draft-ietf-conex-concepts-uses) could help in a mobile communication network, how you would use CONEX mechanisms most likely, and what we should consider for designing the CONEX mechanism.

It's a first draft that we plan to advance a bit in the future, but we hope it's useful enough at this point as input to the current discussions.

Any feedback would be appreciated. If there is interest, we would also be able to present this in Prague.

Best regards,

Faisal, Rolf, Suresh, Ying, Dirk

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 8 Mar 2011 15:30:35 +0100 (CET)

> Any feedback would be appreciated. If there is interest, we would also be able to present this in Prague.

In 3.1 it says that DPI is desireable because of increased traffic volume.

DPI in itself doesn't help with traffic volume but can identify different 
traffic types that can then be acted on. I think the text should reflect 
this. DPI is identification, not action.

3.2

The scenario described in the first paragraph has already happened, at 
least where I am.

Regarding the last paragraph, I'd say it'd work best if there was some 
kind of intelligent scheduling within the single bearer (which is the most 
common deployment for "mobile broadband"), instead of the currently used 
FIFO. This needs to be done at congestion points along the path, for 
instance egress at the base station.

4.2

There is talk about policers here. Do you really mean policing or do you 
mean delying traffic by use of buffering + tail drop when a certain length 
is exceeded? I've seen both done in EPC depending on vendor.

5.

Doesn't the whole system already provide fairness by means of scheduling 
radio and other resources according to user profiles? The whole argument 
of "lots of TCP sessions using a lot of data than the single TCP session 
interactive content one" doesn't apply here since all users are in a 
single bearer anyway?

Conclusion:

In my mind, a mobile network is NOT ideal to deploy CONEX in, because it 
already has a lot of the fairness mechanisms already in it. A users total 
traffic is in a single bearer and users are differentiated on bearers, not 
what's in the bearers exactly. If this works as advertised, resources are 
already fairly distributed between users of the same traffic profile.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dirk Kutscher <[email-masked]>
Date: Fri, 11 Mar 2011 14:58:46 +0000

Mikael,

Thanks for the feedback. Some replies inside.

> this. DPI is identification, not action.

Yes, I agree. We are planning to add more on the overall policing framework.
 
> The scenario described in the first paragraph has already happened, at

Yes, same here. ;-)

We found it useful to re-state this explicitly -- based on experience in discussing capacity sharing ideas in other communities.
 
> instance egress at the base station.

Right -- I would see this as an implementation-specific optimization -- different vendors would be able to have their specific clever scheduling.
 
> is exceeded? I've seen both done in EPC depending on vendor.

This whole section 4 is really trying to explore how the congestion exposure concept and entities such as congestion-contribution-aware policers could be applied to the EPS. There are of course many different options, and we have some further ideas on this. For this draft, we wanted to provide a gentle introduction to the idea and point at things that would potentially require changes as well.
 
> already fairly distributed between users of the same traffic profile.

I guess that's the crucial point of the discussion: whether we can do better than bearer-separation-based fairness.

One important aspect to keep in mind is that congestion exposure is not necessarily about fairness. We are interested in economical resource usage, incentivizing scavenger transport (perhaps within a single user bearer) to provide better performance (lower latency) to more important applications etc.

It is most likely possible to extend the existing resource management mechanisms to do that, but the interesting question is whether congestion exposure can actually be a simpler solution.

Best regards,

Dirk

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