Discussion of ECN API?

Discussion of ECN API?

[Bruce Barnett]

I've been involved with the application perspective of DCCP
programming, or rather - application programming aware of congestion,
and I was wondering if there exists any API for other transport
protocols that make congestion information available to the
application?  In particular, is there any existing API to extract the
ECN information that can be used for a model?  Or if it is missing, -
how should it be specified?

One approach is to provide an array of ECN values. But how big would
this be?  And how would it be packed?  

Or one could return a monotonicly increasing count of ECN failures. But
what is a failure, as there are several kinds.  Some errors should be
handled by the kernel (Routers that don't support ECN, etc.). Others
should be of interest to the application (there is congestion in the
return path).


One could also provide a error percentage, but how would this be calculated?


Anyone have any ideas or resources I could check?

Re: Discussion of ECN API?

[Arnaldo Carvalho de Melo]

I'm not aware of any, at the same time I think DCCP should at least
expose the info on ack vectors,so the question is: is the information
available on ack vectors enough for you (the app writers?)?

- Arnaldo

On 12/19/05, Bruce Barnett <dccp@grymoire.com> wrote:
>
> I've been involved with the application perspective of DCCP
> programming, or rather - application programming aware of congestion,
> and I was wondering if there exists any API for other transport
> protocols that make congestion information available to the
> application?  In particular, is there any existing API to extract the
> ECN information that can be used for a model?  Or if it is missing, -
> how should it be specified?
>
> One approach is to provide an array of ECN values. But how big would
> this be?  And how would it be packed?
>
> Or one could return a monotonicly increasing count of ECN failures. But
> what is a failure, as there are several kinds.  Some errors should be
> handled by the kernel (Routers that don't support ECN, etc.). Others
> should be of interest to the application (there is congestion in the
> return path).
>
>
> One could also provide a error percentage, but how would this be calculated?
>
>
> Anyone have any ideas or resources I could check?
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Discussion of ECN API?

[Bruce Barnett]

> I'm not aware of any, at the same time I think DCCP should at least
> expose the info on ack vectors,so the question is: is the information
> available on ack vectors enough for you (the app writers?)?


Raw information may be harder to deal with, but at least all of the
information is there.  After we have a better idea on the algorithms
needed for intelligent applications, we can provide a friendlier
interface. I don't think we know the best algorithms yet.

I think DCCP-enabled applications that are aware of congestion are key
to the next generation of streaming networking.  TCP-based applications
don't care if the network is congested. Either the data arrives or it
doesn't. but VoIP/DCCP applications need to deal with latency and
reliability, and if quality drops, they must take responsibility.

Consider a VoIP application with a 10% packet loss.  With some
vocoders, a 10% loss is unintelligable. So the application is sending
out 90% of the packets with zero effectiveness.  Those packets are
useless, yet they are contributing to the congestion.  I view this as
abuse to the network in two ways (1) sending out packets that are
contributing to congestion, and (2) doing so in such a way that the
packets are useless once they arrive. TCP doesn't abuse the 
network like this.

Likewise, if the reliability was high, but the latency increased to 2
seconds per packet, then the usefullness of the bandwidth also
decreases as the mouth-to-ear delay increases.

Application adaption is key to minimizing network abuse for
streaming applications like VoIP.


Now we just have to figure out how to do it the right way. :-)