Re: [re-ECN] Pls respond: Do we have a Congestion Exposure community?

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

Bob Briscoe wrote:
> Joao, Marcelo,
>
> We had an interesting retreat at Dagstuhl in Germany, which focused a 
> great deal on this question of whether TE is best done e2e or in the 
> network. While I agree that both are likely to happen whatever anyone 
> decides is best, there was near-unanimity that e2e had more technical 
> merit, not just more deployable.

Agreed, but networks can make an endhost's life a lot easier, i.e. by 
offering disjoint / pre-computed paths over which hosts then balance 
their own traffic to possibly achieve something approaching Wardrop 
equilibrium. Then networks can just signal preference implicitly through 
packet marking to induce endhost behaviour.

To reply to Marcelo's earlier mail: yes, the e2e model is the right 
approach but re-ECN is disruptive enough that many of the choices made 
should be reassessed as some underlying assumptions may no longer hold. 
This is specially true for CC, but also extends into business models and 
security.

Cheers,
Joao.


>
> But to a certain extent this assumes networks can and have put 
> incentives in place for endpoints to do what networks would want them 
> to do.
>
> Of course the near-consensus at Dagstuhl may have been more a 
> reflection of who had invited the participants!
>
> I believe a distinction also needs to be made between moving traffic 
> around offered routes and finding which new routes to offer that would 
> improve load balancing.
>
> The report on the retreat published in CCR and a link to further info 
> is here:
> <http://www.bobbriscoe.net/pubs.html#dagstuhl-fi>
>
> HTH
>
>
> Bob
>
> At 16:32 06/09/2009, João Taveira Araújo wrote:
>> Hi Marcelo,
>>
>> Re-ECN reveals rest-of-path congestion, so any (interested) network 
>> node can estimate how much congestion a given stream of packets is 
>> expected to experience. In the TE case this information might be 
>> useful to balance traffic more efficiently than simply resorting to 
>> load factor and other local information.
>>
>> I also believe it might be an interesting catalyst for new routing 
>> models as it realigns incentives at the transit level. Hesitant 
>> providers might warm up to the idea of providing multiple routes if 
>> there was something in it for them too. As it stands current 
>> multipath work (afaict) is bypassing the network entirely and 
>> providing a pure e2e solution. Not that this is wrong, but it is one 
>> of many approaches. Whether we're gravitating towards it because it's 
>> the only deployable option or on technical merits alone is not 
>> entirely clear to me.
>>
>> Cheers,
>> Joao.
>>
>> marcelo bagnulo braun wrote:
>>> Hi Joao,
>>>
>>> could you expand on the relation between re-ecn and TE/routing?
>>>
>>> Regards, marcelo
>>>
>>>
>>> João Taveira Araújo escribió:
>>>> Hi Bob,
>>>>
>>>> As you know, I'm very much interested in re-ECN, particularly in 
>>>> using some of its properties in other areas like TE/routing. I have 
>>>> cycles to spare so feel free to count on me for 
>>>> reviewing/coding/booing and clapping.
>>>>
>>>> Cheers,
>>>> Joao.
>>>>
>>>> Bob Briscoe wrote:
>>>>> Folks,
>>>>>
>>>>> I'd like to try to arrange a Congestion Exposure (re-ECN) BoF in 
>>>>> Nov at the Hiroshima IETF. If so, we have to notify the area 
>>>>> directors v soon - by 24:00 UTC Mon 7 Sep 09. #1 gating function 
>>>>> for Area Directors: activity on an ietf list.
>>>>>
>>>>> Therefore, pls respond preferably *on this list* if you're 
>>>>> interested in being involved, no matter how insignificantly, e.g.
>>>>>
>>>>> - you want congestion visibility for other stuff you're doing
>>>>>   (but don't intend to work on it itself)
>>>>> - reviewing docs,
>>>>> - alternative way to achieve congestion exposure
>>>>> - participate in mailing list discussion,
>>>>> - co-authoring docs
>>>>> - design ways to do incremental deployment
>>>>> - using code for other stuff you're doing
>>>>> - thinking up new uses for the protocol
>>>>> - breaking it
>>>>> - analysing benefits/costs
>>>>> - implement protocol
>>>>> - implement a demo
>>>>> - running or participating in trials
>>>>> - standing on the sidelines booing or clapping
>>>>> - whatever
>>>>>
>>>>> Perceived problem:
>>>>> Most people want to work on something finite like a new cool 
>>>>> non-TCP-friendly congestion control. Less people want to go into 
>>>>> an pseudo-infinite loop fixing IP to allow other cool stuff to 
>>>>> happen. If you want something like re-ECN to be there, but don't 
>>>>> have the bandwidth to work on it, that's cool too - please say 
>>>>> this - it's still palpable support. And you will be likely to have 
>>>>> review comments related to how you want to use it.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>> ________________________________________________________________
>>>>> Bob Briscoe,               Networks Research Centre, BT Research
>>>>> _______________________________________________
>>>>> re-ECN mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/re-ecn
>>>>
>>>> _______________________________________________
>>>> re-ECN mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/re-ecn
>>>
>>> _______________________________________________
>>> re-ECN mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/re-ecn
>>
>> _______________________________________________
>> re-ECN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/re-ecn
>
> ________________________________________________________________
> Bob Briscoe,               Networks Research Centre, BT Research