On 05/24/2012 03:16 PM, John Leslie wrote:
Harald Alvestrand<harald@alvestrand.no> wrote:
I see that https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ shows that one document is already in front of the IESG; is this a good starting point to read up on it? I think it's worth reading...
I see a clear impact on design choice on how to handle these. I think we should discuss the impact of ConEx here before the BOF in Vancouver. The list's been relatively quiet for a while, so there's room ... the result of discussion may be "too far out to worry about"; ;^)
my 0.01 read is that Conex expects that it has to be deployed in both ISPs and endpoints before it does any good, That's not a correct read of draft-ietf-conex-concepts-uses, IMHO.
There is utility in having the expected-congestion visible at nodes along the path. There is an expectation that at least one ISP along the path will act on it, but it's premature IMHO to say what that action may be. That's what I said, wasn't it?
- has to be at origin, otherwise info won't get inserted - has to be at destination, otherwise info won't get reflected - has to be in the middle, otherwise nobody will act on the info It doesn't have to be at all the ISPs, but at least one ISP. I think.
while the goal for RMCAT is a function that can be usefully deployed even if it's deployed at the endpoints only. Agreed!
-- John Leslie<john@jlc.net>