Re: [MMUSIC] Application to Network Communication

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

> Hi,
> 
>>> I guess my questions will be answered once I read the draft, but I'll ask a couple of high-level questions at this point anyway :)
>> 
>> I am afraid that the draft will open up for more questions than answers.;-)
> 
> Well, at least it's good if the questions come before the draft is published as RFC :)
> 
>>> Q1:	How will you associate the STUN requests with a given media flow? If your answer is based on IP address:port, do you 
>>>                       then assume that there will be only a single flow per IP address:port?
>>> 
>> 
>> The STUN messages are sent on the same 5-tuple as media, so the metadata in the STUN packets needs to describe whatever is being sent on that 5-tuple.
>> 
>> Introducing BUNDLE into this is interesting. But again I think that is up to what the metadata want to describe. If audio and video is flowing on the same 5-tuple, that needs to be described. 
> 
> BUNDLE is one case, but there are also discussions about sending multiple media flows of the same media type, separated by SSRC, on the same 5-tuple. The SDP a=ssrc attribute might be enough to signal that, so you wouldn't need BUNDLE.

That is true. Thanks for the pointer. We some text around multiplexing scenarios and the problems associated with it.

> 
>>> Q2:	You say that the network will provide information using STUN requests. Will the network piggyback information in the STUN requests sent by the ICE endpoints, or will the network generate their own STUN requests?
>>> 
>> Piggyback. The plan is to add attributes the network elements can write information into. That might save some mallocs on the network side. 
> 
> Keep in mind that if one endpoint is ICE lite, it won't send any STUN connectivity check requests (only responses) or keep-alives. That might not be an issue in UA-to-UA scenarios, where both ICE endpoints are typically full ICE. 
> 
> But, if one ICE endpoint is located within the network it will often be ICE lite. Now, I don't think you would have to mandate those to become full ICE, but I guess they at least would need to send keep-alives, in order to allow piggybacking of data in both directions.
> 
Yes. For now we are focusing on solving two problems, how to get better treatment of flows in the network and how to improve ICE path selection. To solve both of these in the ICE-lite scenario I think we need to introduce a MALICE-light version that does what you describe above (Send some conn checks and answer checks with reflected metadata attributes.)

Will post the draft later today.
.-.
Pål-Erik

> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com] 
>> Sent: 28. kesäkuuta 2013 10:13
>> To: Christer Holmberg
>> Cc: mmusic
>> Subject: Re: 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
>> 
> 