Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

"George, Wes" <wesley.george@twcable.com> Mon, 22 July 2013 20:18 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB2611E813F for <int-area@ietfa.amsl.com>; Mon, 22 Jul 2013 13:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 aiVohWc0Lubi for <int-area@ietfa.amsl.com>; Mon, 22 Jul 2013 13:18:13 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9022811E8153 for <int-area@ietf.org>; Mon, 22 Jul 2013 13:18:06 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.89,721,1367985600"; d="scan'208";a="107722332"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Jul 2013 16:16:56 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 22 Jul 2013 16:18:05 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "int-area@ietf.org" <int-area@ietf.org>
Date: Mon, 22 Jul 2013 16:18:04 -0400
Thread-Topic: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt
Thread-Index: Ac6Bn0gbxl2mtmX2RumGmT6rK69PKgB822jgAAhZAoAAAX6WIAANU3hgABdWeIAAsgzSUA==
Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439111259@PRVPEXVS15.corp.twcable.com>
References: <94C682931C08B048B7A8645303FDC9F36EE2DDB4FE@PUEXCB1B.nanterre.francetelecom.fr> <45A697A8FFD7CF48BCF2BE7E106F0604090C8510@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE2DDB59F@PUEXCB1B.nanterre.francetelecom.fr> <92B7E61ADAC1BB4F941F943788C08828048B669B@xmb-aln-x08.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE2DDB748@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE2DDB748@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 20:18:19 -0000

I think this is an interesting and potentially useful draft.

In section 3.2.3, acceptable path attributes, I think there needs to be some more granularity available in order to properly express the needs of a given application. Specifically, you need to make a distinction between maximum sustained delay and peak, momentary delay (jitter), as often applications can be tolerant of one but not the other. You also may need to represent a max sustained loss vs a max momentary peak loss, and define a timescale upon which to measure those maximums, since an absolute value for loss (e.g. 1%) can mean vastly different things depending on the measurement timescale and type of payload.

You may even want to offer a way to represent near-infinite (tens or hundreds of seconds) delay tolerance, perhaps expressed in terms of a "must be delivered by" or expiration date. What I have in mind here is cases where you have bulk background transfers that have relatively high bandwidth requirements, but are very tolerant of delay and can be therefore buffered, deferred, or routed on very sub-optimal paths. For example, if I'm loading content onto a cache, and it cannot be accessed before a certain date and time due to blackout restrictions, that flow has near-infinite delay tolerance up until just before that date and time when it must be available. Armed with that knowledge, the network can schedule when it actually does that transfer (and what path it takes) to ensure best utilization of the network's spare capacity.

Thanks,

Wes George


Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.