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

Hi George, 

Thanks for your comments. Please see inline.

> -----Original Message-----
> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf
> Of George, Wes
> Sent: Monday, July 22, 2013 1:18 PM
> To: int-area@ietf.org
> Subject: Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-
> flow-metadata-framework-01.txt
> 
> 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. 

I see your point. We actually considered including jitter as a separate attribute. We decided to leave it out mainly in an attempt to keep the attribute set small, yet sufficient. We can certainly add jitter, though I'd like to hear a few more opinions on this.

> 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.

Yes, the loss needs to be computed over a time period and/or number of packets for the percentage to make sense. I was envisioning this as an indication of momentary peak loss rather than sustained loss, but that is dependent on the chosen time period and packet rate. What do you think would be reasonable values for the interval? Do you think it is possible to choose this interval such that one loss measurement is sufficient?

> 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.

Hopefully setting this attribute to the maximum value in the defined range is sufficient to accomplish this.

Cheers,
Charles

> 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.
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area