[Iccrg] Re: ECN marking over wireless networks

[John Leslie]

sebastien.jobert <sebastien.jobert at orange.com> wrote:
> 
> The question that is raised here, I believe, is to understand how ECN
> marking over the radio segment can help (if it helps...) when combined
> with existing/already implemented radio resources sharing algorithm
> (e.g. PF). And how this signal might interact with other mechanisms
> (TCP, incentives, ...) to improve the situation in case of radio
> congestion compared to the case where ECN marking is not used.

   First principle: ECN _can_ signal congestion faster than a packet
loss can be inferred by the sender. This is an unmitigated good-thing.

> At the end, I agree that it might not be the most optimal solution
> (but I'll tend to think that wireless systems always require some
> kind of compromise - you might optimize one particular parameter at
> the expense of another).

   Agreed: ECN can't signal congestion to the sender as fast as a
backpressure signal from the wireless access point. But we do have a
standard for ECN, whereas ICMP source-quench has been thoroughly
deprecated.

> I also agree with Jim that fairness should refer to "transmission
> opportunities" in this type of wireless systems rather than bandwidth.

   I agree as well: transmission opportunities tend to be the limiting
factor. (This is not pure packet-counting, but is poorly correlated
with packet size.)

>... What you mentioned about bugs on different drivers makes me think
> that some sort of documentation about expected behavior for ECN
> marking would be useful.

   Not sure what we can say...

> Thanks also for the information about CoDel AQM (that I did not know
> before) to be considered instead of RED. We'll investigate this.

   CoDel fundamentally says to discard packets based on time-in-queue
(and doesn't yet refer to ECN-marking). I see great promise for CoDel
ECN-marking instead of drop, but so far I know of no specification for
this. Specifying such a thing seems very worthwhile: I don't know the
best route for doing so...

>... Note that this heterogeneity problem is quite common in practice,
> and applies also to other technologies (the various behaviors of
> forwarding engines of IP routers is a very good example), but it
> fortunately did not preclude developing in the past generic models
> for the purpose of progressing a common understanding of certain
> mechanisms.

   +1

> I still really can see benefits in trying to document such ECN marking
> algorithms over wireless networks, even if in practice, a real
> implementation might differ from those general descriptions.

   In practice, implementations are likely to be all-over-the-place.

   In particular, we should expect ECN marking to follow AQM with
sub-optimal parameters. Observing the problems is definitely ICCRG work.
I dare to hope that ECN marking following CoDel could be standardized
sufficiently to become a comfortable choice.

> One reason justifying this: ECN marking over wireless network is
> mentioned in different documents (e.g. 3GPP TS 36.300, 26.114,
> draft "Mobile Communication Congestion Exposure Scenario" in Conex WG,
> ...), how would you use it in practice if you have no idea about what
> is done by the equipment?

   There is certainly a problem perceived here; but I'm not sure there's
a real problem. So long as the ECN marking applies equally to flows,
those flows can apply equivalent throttling of send rate, and we'll be
better off than without ECN.

   OTOH, actual optimization _will_ work better if the sender doesn't
have to guess what the ECN marks actually reflect...

> That being said, I fully agree that no general recommendation can be
> done at this stage, but I would also really encourage people to work
> on this so that some sort of general recommendations could be developed
> in the future.

   I wouldn't agree that "no" general recommendation is appropriate, but
certainly any recommendation must be "tentative" at this point.

> I also agree that Conex approach might help on the fairness item, with
> some adaptations.

   That discussion probably belongs on the ConEx list...

--
John Leslie <john at jlc.net>