Re: [re-ECN] RE-ECN without ECN.

[phil] one follow-up on the comment below about GTP-U tunnels. Getting
congestion marking correct for tunnels other than IP/IPsec is certainly
important - I guess in general that has to be taken up with other
standards bodies. There is some guidance in an earlier version of Bob's
tunnel draft about guidelines for what needs to be done for a generic
tunnel type; it disappeared in more recent versions (in order to focus
on ietf specifics). I think it might be worth resurrecting this content
at some point - maybe once the tunnel draft has progressed in ietf
(currently, it's nearly done in tsvwg [I think!])
phil

> 
> I agree all around.   Bob has been putting a lot of effort into making
> sure that the specifications for tunnels say the right things.   What
> I don't know is if there have been any measurements of the population
> of devices that do busted things, such not updating the inner ECN bits
> from the outer header on decapsulation.   (But note that this is
> busted for all variants of ECN).

Again to the mobile network. One of the most (variably) congested
networks
out there is the mobile backhaul network. In 3GPP, this is carried in a
tunnel type called GTP-U. I've not found GTP-U implementations to be
much for moving markings from outer to inner (e.g. DSCP). I've done
a quick check on a couple of networks, and did not observe ECN marked
on the inner, so i can't say if they support ECN 'moving the mark'.

One of the things i am hopeful to use re-ECN for in our products is
as an indication of backhaul health (and i dream someday of RF health)
so that we can break reporting information down by 'this is what
congested/near-congested/non-congested links are doing'. So i'm
hopeful it can be made to work in GTP-U (which implies getting
ECN basis working).

--don

_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn