Re: [MMUSIC] Application to Network Communication

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 28 June 2013 12:19 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45B521F9C91 for <mmusic@ietfa.amsl.com>; Fri, 28 Jun 2013 05:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.979
X-Spam-Level:
X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PAI1HkVv7wK for <mmusic@ietfa.amsl.com>; Fri, 28 Jun 2013 05:19:32 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D3D6C21F846E for <mmusic@ietf.org>; Fri, 28 Jun 2013 05:19:26 -0700 (PDT)
X-AuditID: c1b4fb30-b7ef76d000004bbc-2e-51cd7f4b80ee
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 12.9D.19388.B4F7DC15; Fri, 28 Jun 2013 14:19:23 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 14:19:23 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
Thread-Topic: Application to Network Communication
Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRAgAG89ACAAABJEA==
Date: Fri, 28 Jun 2013 12:19:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BE5EA@ESESSMB209.ericsson.se>
References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com>
In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra53/dlAg8MrtCymLn/MYvH++koW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj/9NNrAXHtSqeXbZqYFyr1MXIySEhYCKx 9Mg/JghbTOLCvfVsXYxcHEIChxkleo48ZIRwFjFKTPrwEyjDwcEmYCHR/U8bpEFEwFii+chR dhCbWUBGYsbZRiaQEmEBQ4kHD30hSowkpv7tZYGwnSRuzH/JBmKzCKhKrPlxiRXE5hXwlVhw ehMLxKrLjBLPFneBHcQJlFg4fxFYMyPQcd9PrWGC2CUucevJfKijBSSW7DnPDGGLSrx8/I8V wlaUaH/awAhRrydxY+oUNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWM 7LmJmTnp5eabGIERcnDLb4MdjJvuix1ilOZgURLn3ax3JlBIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QD4/EsU/WKfOUnnH8ckl/YHnEUc54i6/lt71+DmMIe01yNwuTqRp+pwedmX5EOnmq5 b1PFUY73y8uZPmo9ma58bNrcTFbtJ3Gqbp+3OEXVluwqLxTb1W438YHDRO1bQeG8Zp/kWfew +Chd4f0mx5idKBqzYiXfocnm8QzVZyKfruk8b/dk/9dpSizFGYmGWsxFxYkAANV2Kl4CAAA=
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Application to Network Communication
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2013 12:19:43 -0000

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

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?

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?

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