[e2e] applcation layer!!!!

[Ian McDonald]

>  Hi all,
>         As the DOS attack issue is getting heated up in the group. I would like to divert your attention a bit.
>   As we know the current trends in the Internet technology points to an increasingly heterogeneous network consisting of links of vastly different characteristics. Satellite networks, WLANS, mobiles will be ubiquitous and an integral part of the future Internet.  As we have seen all the layers of OSI model evolving , can anyone throw some light how application layer is evolving inorder to take into account the heterogenity of the network.
>  Is any changes in the application framework been proposed which can give a better perfomance taking into account the heterogenity of the network.
>
>  I mean to say has anyone looked from the application point of view, or is it better to keep the application unaware of the medium.
>
>  I'm sorry if the above question is irrelevant or may be stupid but atleast I would expect some comments....
>
Hi there,

I think that there can be improvements made by making the application
aware of variables such as transmit rate, loss etc so the codecs or
apps can make changes in a better way.

I also think that there can be quite a bit done in the transport layer
also. Here is an entry from my blog where I describe what I am
currently doing: (Also my research proposal talks about this a bit if
you want to read it - get it from my page mentioned in the URL in my
signature).

In my literature review I found a number of references to packet
priority in regards to multimedia traffic. My particular interest is
in real time applications e.g. VoIP, video conferencing.

One method that I found was to split the traffic into layers and send
the highest priority layer first. Another method was to have a ring
buffer at the transport layer where packets could get pulled up until
they were sent and replaced with more appropriate packets.

This has had me thinking for a while now and I think that what I will
do is send information about the packet along with the packet to the
transport layer. This information will include:

    * type of packets (video channel (and layer if appropriate), audio
channel, control)
    * expiry time

For video packets it will include how many packets make up the frame,
and which packet this is in the sequnce of that frame. Later on I will
also put in a concept of layer also probably if rendering in a
progressive manner.

Audio and control packets should fit within one packet.

The application would send using sendmsg instead of write to send this
control information.

The transport layer (DCCP in my first round of coding I imagine) would
then send packets in the correct priority order basically following a
set of rules something like:

    * if the packet has expired discard it. This time will actually
include the RTT which it keeps track of so we can say "this packet
must reach the destination within x msecs"
    * send control information first
    * send audio second
    * send video third. Check if the whole frame can be sent before
the expiry time. If it can't and there is another video frame then
discard and start sending that frame

Obviously it will be a little bit more complicated than that but I
think this is a reasonable approach and we should get more relevant
data through as DCCP will know pretty exactly the state of the
connection.

In summary - get the transport layer to send the best packet next!
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand