Re: [conex] Potentially interesting ConEx problem

So as an intermittent TCP person, I agree with them: this does not
belong at the TCP layer, but at some slightly higher serving services
layer, because it is has to be coupled to things like load balancers,
etc.  Per server state isn't useful.

Which is not the same as saying the idea isn't valuable, it is just
that TCP itself isn't quite the right place.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.

On Tue, Mar 5, 2013 at 9:20 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 5 Mar 2013, Matt Mathis wrote:
>
>> The question I was asking was can ConEx help the content provider know
>> which bottleneck prevails?  Bob?
>
>
> I tried to get the TCP people look into this, but got shot down. They didn't
> feel TCP would work better by knowing more, or I guess they didn't want to
> handle th complexity.
>
> My idea was that TCP would over time "find out" what the access looked like
> if it indeed was the only thing congesting, and even that the connection
> manager on the machine would inform TCP what the properties of the primary
> connection was (speed, buffering, retransmits, half/full duplex etc), and if
> something substantial (like the link going down or coming up, speed changed
> etc) happened, TCP would be informed of this.
>
> They felt it was better to have TCP find out by itself instead of getting
> fed this information via some API.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex