[MMUSIC] Application to Network Communication

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Thu, 27 June 2013 08:35 UTC

Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5C47E21F9C7A for <mmusic@ietfa.amsl.com>; Thu, 27 Jun 2013 01:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JS2qIb874bwg for <mmusic@ietfa.amsl.com>; Thu, 27 Jun 2013 01:35:37 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id BCBEF21F9C79 for <mmusic@ietf.org>; Thu, 27 Jun 2013 01:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1566; q=dns/txt; s=iport; t=1372322136; x=1373531736; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WAsHJDR3DE96SznZTciet94OP8cFalByJIReLp7kPf0=; b=FGTP48iz2fhIrQl3schWLiXLOfN4pVRWQdL+VT+aaVEutn4jJYLa7909 5lNzNcHlMfz2XjVGFzSShWnW/O+AqQ2ut7TFIyw6RQrmd4u2GUgslJYAg lM21fTygc9EVrI7TZqpox2ZXuR2QBlXQImtyeD+f2miuR1oMXV4yyxzgk s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAFX4y1GtJV2Y/2dsb2JhbABbgwl6vwN9FnSCJQEEZyQBKlYnBBsTh3OaAqA6jySDOmEDiGqgIIMRgig
X-IronPort-AV: E=Sophos;i="4.87,950,1363132800"; d="scan'208";a="228014593"
Received: from rcdn-core-1.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jun 2013 08:35:35 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com []) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5R8ZZMW029060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Thu, 27 Jun 2013 08:35:35 GMT
Received: from xmb-rcd-x06.cisco.com ([]) by xhc-rcd-x15.cisco.com ([]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 03:35:35 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: mmusic <mmusic@ietf.org>
Thread-Topic: Application to Network Communication
Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnbw==
Date: Thu, 27 Jun 2013 08:35:34 +0000
Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B1A61294F5CCC74D8D210B28D5938205@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Thu, 27 Jun 2013 08:35:43 -0000

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.

Pål-Erik Martinsen