[e2e] applcation layer!!!!

[mhufe@UDel.Edu]

SCTP offers some interesting features that could make life a little easier at the application layer. A single association can contain multiple streams. So, audio could be packaged in one stream, video in another, and control on yet a third. 

There's also an extension called PR-SCTP (partial reliability). The sending application can specify a userful lifetime to the transport layer for a particular chunk of data. If the data isn't acknowledged within a specified time duration, the data is discarded. 

Multi-homing is another feature provided by SCTP. An association from one host to another can be made over multiple interfaces. That is, host A might have an ethernet interface and a wireless interface. Host B might two or more similar interfaces. An application on host A could form an association with an application on Host B through any combination of interfaces, determined at the transport layer.

The original intent of multi-homing was fault tolerance. Data for an association is sent across a single interface pair under normal circumstances. If there is a failure anywhere along the path, then the association can continue exchanging data along an alternate path in a manner that can be transparent to the application, with the exception of the delays related to detecting the primary path failure. 

There's also some research being done in the area of Concurrent Multipath Transfer (CMT) using SCTP. For more information, check out this link: 
http://www.eecis.udel.edu/~amer/PEL/poc/index.html. 

- Mark Hufe 

Ian McDonald wrote: 

>> 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 
>   
>