Re: [MMUSIC] Application to Network Communication

On Jun 27, 2013, at 11:42 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
> I am not really sure what you mean by "how network should treat different streams".
> 
> What kind of network entities are you referring to, and what kind of treatment?
> 

Routers, switches, firewalls, NATs, ALGs, SBCs, B2Bs. And a few acronyms I probably don´t know exist. In short any device in the network that rightfully or not is or inserts itself in the media path. 

The name of the draft that currently is being drafted is MALICE (Metadata Attribute signaLing with ICE). The basic idea is to signal a set of descriptive metadata attributes in some of the STUN messages that are sent when an agent does ICE. The way STUN is crafted makes it easy for network entities to distinguish the STUN metadata packets and act on the information. 

One of the short term use cases this can solve is the problem where DSCP markings can be lost when the packet crosses administrative domains. If metadata is sent in-band with STUN it can for instance describe this stream as video. If SRTP is in use it would be hard/impossible for any network entity to know that the stream is video without this in-band metadata. So if network A and B want to treat video differently by having their own DSCP markings they can now do this. 

MALICE tries to just be a framework for sending the metadata, thus enabling application to network communication. It also tries to describe how routers can add useful information to the metadata packets, and how that information can be sent back to the application without relying on address spoofing or opening up for multiplying attacks. This opens up for network to application communication. Like ECN, but more descriptive and it works on more platforms. (I am no expert n the area, but I am under the impression that it is difficult to get the complete IP header up to the application on some platforms)

This can be used in a multitude of ways; Optimising the ICE path selection based on actual network feedback, making it easier for video application to choose the correct starting bandwidth, can enable better down/and up speeding of video streams. Hopefully there are a lot of other use cases as well. 

I don´t expect this to be an easy problem to solve. So for now I think the big question is:
"Is it worthwile trying to come up with machanisms that enable better application to/from network communication?"

.-.
Pål-Erik

> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Pal Martinsen (palmarti)
> Sent: 27. kesäkuuta 2013 11:36
> To: mmusic
> Subject: [MMUSIC] Application to Network Communication
> 
> Hi All,
> 
> We see a need for better application to network communication to convey how the network should/could treat the different streams described in the medalines of the SDP. This is especially important as video codecs have become very elastic regarding network bandwidth. It would be useful for the network to know the nature regarding the usage of the video stream. The network could treat the stream very differently whatever it is realtime video requiring low latency and high bandwidth or is it a more static presentation flow carrying a slideshow. Getting information from the network to the application can also prove to be useful.
> 
> Todays existing solutions can be difficult to implement on some devices as the information is carried in the IP header or the markings in the packets is ignored across administrative domains. Other solution treats the network as a black box and tries to fix problems when they are discovered. Both the network and the application would benefit if information regarding things that is about to happen as opposed to just happened could be conveyed.
> 
> We are considering extending ICE connectivity checks and keepalives (STUN) to provide this communication from the endpoint to the network and from the network to the endpoint.
> 
> Are other folks seeing this problem as well, or are existing techniques and throwing bandwidth at the problem sufficient today and sufficient tomorrow?
> 
> Any comments, feedback and ideas are very welcome.
> 
> Regards
> Pål-Erik Martinsen
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic