[Iccrg] Re: [tcpm] ECN feedback discussion

[John Leslie]

Scheffenegger, Richard <rs at netapp.com> wrote:
> 
> I'm back at a decent computer; this is the paper which mentions how the
> highest congestion rate on one of multiple congested routers can be
> determined (needs to know the number of hops though; with L2-to-L3
> mapping of marks, simple TTL assumtions may not be enough).
> 
> "ECN verbose mode: a statistical method for network path congestion estimation", Remi Diana, Emmanuel Lochin, 2010
> 
> http://arxiv.org/pdf/0910.4455v2.pdf

   I think I mostly followed this paper; but deployment of its mechanism
seems iffy, and I'm not sure we could reach consensus on the right
reaction to minor congestion twice along the path.

> I think Emmanuel is listening on one of these groups;

   I'm limiting this reply to <iccrg> -- I doubt there's work for tcpm
yet.

> For the signaling aspect, using ECT1 as the initial signal of a
> high-density marking scheme, and CE for both low-density and when
> two high-density schemes overlap (mark the same packet) would be an
> improvement along the lines mentioned in that paper.

   That doesn't sound sufficient; and the ect0 -> ect1 signal for
low-threshhold seems more deployable.

> However, even the current TCP ECN Nonce feedback wouldn't worki
> properly, as a feedback channel from the receiver to the sender.
> I'm deliberately excluding other protocols for now...

   I suspect all of this will prove more deployable in transport
protocols other than TCP; but I think ECN marking should be strictly
network-layer (without reference to the transport).

> As Matt suggested, if such a scheme were to be standardized, the
> balance between feedback for CE and ECT(1) would generally shift
> more to ECT(1); the codepoint scheme described in
> draft-kuehlewind-tcpm-accurate-ecn could be adapted to that easily...

   Matt is an optimist!

   Actually, there are a number of areas where ect0 -> ect1 -> ce
could be put to good use -- but we need to get some traction in
ICCRG first.

--
John Leslie <john at jlc.net>