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

[João Taveira Araújo <[e-mail]>]

Inline

Matt Mathis wrote:
> Here is a fun little tidbit for people to think about, while others
> resolve some of the non-technical issues surrounding launching the
> conex.
>
> For all modern reliable protocols over non-ECN networks (where loss is
> the primary congestion indicator), the amount of duplicate data is a
> direct measure of the down stream congestion.    (e.g. If I observe
> both a data packet and its retransmission, then the first transmission
> was lost someplace downstream).    This is because for all modern
> protocols, the sender almost never sends data that the receiver
> already holds.
>   

Except it's not transport oblivious, so you'd have to a) redesign the 
solution for every new transport protocol or b) expect a single 
transport protocol to be all-encompassing. Won't nitpick since this is a 
thought experiment though...

> If you add the assumption that the network itself does not reorder
> packets, then the number of out-of-order packets is a direct measure
> of the upstream congestion.  (e.g. the first transmission was lost,
> and I see the retransmission).
>
> This is sufficient information to implement many of the proposed uses
> for RE-ECN marking.
>
> For example, the bottleneck for problematic flows can be moved
> upstream so that they are less disruptive to other users, by
> throttling the amount of duplicate data permitted through an ingress
> router.  In the extreme case, when a particular flow exceeds its quota
> for duplicate data, you drop the retransmissions which will
> (eventually) cause it to run out of receive window and take a timeout.
>  More polite would be to pass the retransmission, but then discard the
> next in-order packet on the same flow, normally causing it to slow
> down.  There are some details to be worked out...
>
> The point being that for non-encrypted standard transports, many
> RE-ECN like things can be implemented unilaterally, without global
> deployment of complicated, subtitle and hard to verify new protocol
> features.

You'd be missing one of the most important features however - that 
information is verifiable across borders by both parties. An ISP can 
throttle the duped packets, but why would it voluntarily hinder its 
customers when the downstream transit domain is unable to verify whether 
such enforcement is taking place?

Congestion may come from within the ISP itself, but I'm not certain the 
ISP can reliably infer the location of such congestion at the ingress. 
Something like multipath TCP would also make it very hard to figure out 
whether or not a packet is retransmitted ... which would make a great 
incentive for deploying  mtcp.

Joao.