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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 15 Jul 2013 21:07:17 +0000

We have submitted and would appreciate comments on the following draft. It provides a framework for applications and network devices to communicate characteristics and service attributes for traffic flow. One aspect we anticipate to be of particular interest to this audience is the use of IPFIX in the information model we defined.

Cheers,
Charles

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 15, 2013 1:41 PM
To: Toerless Eckert (eckert); Amine Choukir (amchouki); Reinaldo Penno (repenno); Charles Eckel (eckelcu)
Subject: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

A new version of I-D, draft-eckert-intarea-flow-metadata-framework-01.txt
has been successfully submitted by Toerless Eckert and posted to the
IETF repository.

Filename:	 draft-eckert-intarea-flow-metadata-framework
Revision:	 01
Title:		 A Framework for Signaling Flow Characteristics between Applications and the Network
Creation date:	 2013-07-15
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-eckert-intarea-flow-metadata-framework-01.txt
Status:          http://datatracker.ietf.org/doc/draft-eckert-intarea-flow-metadata-framework
Htmlized:        http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-eckert-intarea-flow-metadata-framework-01

Abstract:
   This document provides a framework for communicating information
   elements (a.k.a. metadata) in a consistent manner between
   applications and the network to provide better visibility of
   application flows, thereby enabling differentiated treatment of those
   flows.  These information elements can be conveyed using various
   signaling protocols, including PCP, RSVP, and STUN.

The IETF Secretariat

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 11:13:42 +0200

Dear Charles, all,

The idea of an application sending flow characterization messages to the network is interesting. This is an idea which is worth to be discussed and challenged. Thank you for writing this document.

The proposed framework makes sense in some contexts but I'm afraid it does not solve the limitations you listed in the document (e.g., avoid some classification functions in the network). The framework as it is won't simplify the network side since in addition to legacy tools, a new function to intercept the flow characterization messages will be needed. The benefit of the approach depends on the willing of application developers to signal the flow characteristic to the network. 

IMHO, it would be useful if the document elaborates on deployment aspects and what are the facilitators to ease adoption of such approach. For example, why an application relying on HTTPS would sent a non-encrypted flow characterization message for analytic purposes? What is the role of a CPE in such model? How to trust the data sent by an application? These are examples of points which should be further discussed in the document. 

If the purpose of the document is not to claim the limitations you identified will be mitigated but instead this framework is an additional tool at disposal for implementers/operators/etc to ease service ordering and delivery, then a note should be added to the draft. This will be helpful to avoid any confusion.

Personally, I'm not a fun of solutions which requires explicit resource invocation before making use of a subscribed service. This mode should not be generalized (it does make sense if a very few services rely on that mode). I understand there are deployment cases which would rely on such mode but this should be discussed in the document too. 

I didn't understood well why the encoding is discussed in this document. The focus should be on the information model not data models (which are protocol-specific).

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la
>part de Charles Eckel (eckelcu)
>Envoyé : lundi 15 juillet 2013 23:07
>À : [email-masked]
>Objet : [Int-area] FW: New Version Notification for draft-eckert-intarea-
>flow-metadata-framework-01.txt
>
>We have submitted and would appreciate comments on the following draft. It
>provides a framework for applications and network devices to communicate
>characteristics and service attributes for traffic flow. One aspect we
>anticipate to be of particular interest to this audience is the use of
>IPFIX in the information model we defined.
>
>Cheers,
>Charles
>
>_______________________________________________
>Int-area mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/int-area

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 14:11:21 +0200

Hi Reinaldo, 

Please see inline. 

Cheers,
Med

>De : Reinaldo Penno (repenno) [mailto:[email-masked]]
>Envoyé : jeudi 18 juillet 2013 12:41
>À : BOUCADAIR Mohamed OLNC/OLN; Charles Eckel (eckelcu); [email-masked]
>Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
>intarea-flow-metadata-framework-01.txt
>
>Hi Med,
>
>Thanks for your review. Inline with [RP]
>
>On 7/18/13 6:13 AM, "[email-masked]"
><[email-masked]> wrote:
>
>>Dear Charles, all,
>>
>>The idea of an application sending flow characterization messages to the
>>network is interesting. This is an idea which is worth to be discussed
>>and challenged. Thank you for writing this document.
>>
>>The proposed framework makes sense in some contexts but I'm afraid it
>>does not solve the limitations you listed in the document (e.g., avoid
>>some classification functions in the network). The framework as it is
>>won't simplify the network side since in addition to legacy tools, a new
>>function to intercept the flow characterization messages will be needed.
>
>[RP] Interception is only needed with some transports. We should certainly
>highlight that.
>
>>The benefit of the approach depends on the willing of application
>>developers to signal the flow characteristic to the network.
>
>
>[RP] Yes. I believe this is somewhat a chicken and egg thing. Because such
>functionality was never truly available in the network, there was no
>incentive to applications developers.
[Med] Makes sense. This is why I see this approach as a new tool in addition to existing ones rather than presenting it will remove immediately some of the limitations of current designs. This can be highlighted in the document.  

>
>>
>>
>>IMHO, it would be useful if the document elaborates on deployment aspects
>>and what are the facilitators to ease adoption of such approach. For
>>example, why an application relying on HTTPS would sent a non-encrypted
>>flow characterization message for analytic purposes? What is the role of
>>a CPE in such model?
>
>
>[RP] I believe the end-point making the request for flow characteristics
>will be the CPE in many cases where the applications is not metadata
>aware. In other words, the CPE makes the request on behalf of applications.
[Med] I'm more interested in this CPE flavor (managed CPE) since it avoids relying on applications to benefit from the added value of this approach. This is worth be discussed in the document too. 

>
>>How to trust the data sent by an application? These are examples of
>>points which should be further discussed in the document.
>
>
>[RP] I think this depends on the transport. Some transports like PCP or
>STUN have some built-in authentication.
[Med] The question is not whether a secure transport is used or not but to what extent the flow description is accurate (e.g., send fake flow description, systematically request treatment with higher priority, etc.).

>
>>
>>
>>If the purpose of the document is not to claim the limitations you
>>identified will be mitigated but instead this framework is an additional
>>tool at disposal for implementers/operators/etc to ease service ordering
>>and delivery, then a note should be added to the draft. This will be
>>helpful to avoid any confusion.
>>
>>Personally, I'm not a fun of solutions which requires explicit resource
>>invocation before making use of a subscribed service.
>
>
>[RP] Me neither. I was hoping the draft did not come as that. The idea
>here is that any metadata could be send before or after connection is
>established and reservation is not required at all. In other words,
>applications will work as always have but could request metadata service
>if they so desire. If request is denied, everything continues to work as
>is.
>
>
>>This mode should not be generalized (it does make sense if a very few
>>services rely on that mode). I understand there are deployment cases
>>which would rely on such mode but this should be discussed in the
>>document too.
>>
>>I didn't understood well why the encoding is discussed in this document.
>>The focus should be on the information model not data models (which are
>>protocol-specific).
>>
>>Cheers,
>>Med
>>
>>>URL:
>>>http://www.ietf.org/internet-drafts/draft-eckert-intarea-
>>>Status:
>>>http://datatracker.ietf.org/doc/draft-eckert-intarea-flow-
>>>metadata-framework

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 18 Jul 2013 10:41:21 +0000

Hi Med,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jul 2013 07:58:44 +1200

On 19/07/2013 00:11, [email-masked] wrote:
...
> [Med] The question is not whether a secure transport is used or not but to what extent the flow description is accurate (e.g., send fake flow description, systematically request treatment with high…

This of course is why the diffserv model assumes that traffic will
be reclassified at domain boundaries, since you can't trust what your
neighbour tells you about QoS requirements. This proposal would be no
different in the general case; flow metadata needs to be trustworthy.
If not it will be a recipe for theft of service or DoS.

Why is this an intarea topic? To my mind it fits in tsvwg, which is
currently discussing things like QoS for rtcweb.

   Brian

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 18 Jul 2013 20:06:57 +0000

Hi Med,

Thank you for your review and corresponding comments. Please see inline.

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, July 18, 2013 5:11 AM
> To: Reinaldo Penno (repenno); Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [Int-area] FW: New Version Notification for draft-eckert-intarea-
> [Med] Makes sense. This is why I see this approach as a new tool in addition
> to existing ones rather than presenting it will remove immediately some of the
> limitations of current designs. This can be highlighted in the document.

[cue] Good point. We do not expect or require all applications and network elements to start using this mechanism in order for it provide value. As you suggest, this is one more tool in the toolset, and it may be used in combination with other existing tools. We can certainly add text to clarify this.
 
> [Med] I'm more interested in this CPE flavor (managed CPE) since it avoids
> relying on applications to benefit from the added value of this approach. This
> is worth be discussed in the document too.

[cue] Agreed. This is what we describe as "Proxy originated information" in section 3.1.4.1 (http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-01#section-3.1.4.1). Does this address your concern?

> [Med] The question is not whether a secure transport is used or not but to
> what extent the flow description is accurate (e.g., send fake flow description,
> systematically request treatment with higher priority, etc.).

[cue] Section 3.1.4.2 (http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-01#section-3.1.4.2) touches on the authentication requirement, but we need to address authorization as well.   Applications may not be authorized to request network resources, but instead authorization has to first be obtained from a network element such as a call controller or policy element. We will add a discussion of this. As Reinaldo pointed out, the transport may provide some mechanisms, but we plan to have mechanisms provided within transport independent encoding as well (for additional details see http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-01#section-2.2.8).

Cheers,
Charles

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 18 Jul 2013 21:41:32 +0000

Hi Brian,

Metadata has many uses and not just QoS.

Therefore we believe int-area to be appropriate. What are your thoughts?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jul 2013 11:20:40 +1200

> Metadata has many uses and not just QoS.

Sure, but some of them clearly concern layers above 3.

> Therefore we believe int-area to be appropriate. What are your thoughts?

I think this is a case where early discussion in TSVWG would avoid
problems later. In the end the choice of WG doesn't matter as long as
cross-area issues are caught as soon as possible.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Jul 2013 18:38:47 -0700

Brian,

Let me give you a comparison: I think DNS is a system with
a standardized data-model for information about specific objects,
primarily hosts and services. The result/action from using DNS is
most commonly some TCP connection(s). That does not make DNS a
TSV target. The metadata framework is in my eyes about a system
with a standardized data-model for traffic-flows and the result/action
is most commonly some form of QoS for the traffic flows. Go figure.

Having said this, we asked to preesent in TSVWG as well, but it does 
not seem as if it would get onto the TSVWG WG agenda. I think there 
would be good collaborators to be found from TSV because like DNS
i would expect that the folks interested in the actions taken
have an interest to build a data-model to make their actions easier.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Jul 2013 20:12:37 -0700

> [Med] I'm more interested in this CPE flavor (managed CPE) since it avoids relying on applications to benefit from the added value of this approach. This is worth be discussed in the document too. 

See section 3.1.4.1 which talks about proxies. The problem really is where
the proxied information comes from. If the proxy is doing DPI inspection to
deduce it or some configured mappings, then it's likely going to be unreliable
(encryption) or suffer from problems in getting it provisioned.

To me these inspecting proxies are a way to get a foot in the door with
the method while it takes its time to persuade app-developers (or middleware
like browsers) to signal the information explicitly (couple of years ?...).

> [Med] The question is not whether a secure transport is used or not but to what extent the flow description is accurate (e.g., send fake flow description, systematically request treatment with high…

Right. That was the intention of 3.1.4.2. Ultimately the network taking
action on the metadata needs to trust the authenticated identity
associated with the attributes to not lie about the attributes - OR
enforce the semantic of the attributes signalled.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Jul 2013 20:40:04 -0700

> (encryption) or suffer from problems in getting it provisioned.

In a prior life, we IETF standardized IP Multicast SSM which does require
application upgrade (signal S,G), and then we and other vendors implemented
what we call "SSM mapping" to work around that (not requiring application
update). Call it an SSM proxy. No vendor brought this into the IETF
because we always wanted to see this positioned as a temporary transition
technology and not make it too attractive to run forever. 

Now, you don't want to know what really is deployed in networks and what
strategies customer apply. Lets just say that SSM mapping is very successfull.

So, to a degree you can account my above paragraph either as 
"famous last words" or "don't give up the good fight". So i am all for
standardizing any proxy methods the IETF thinks makes sense to standardize.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jul 2013 16:15:05 +1200

> is most commonly some form of QoS for the traffic flows. Go figure.

Well, yes, and flow handling and QoS seems to be a regular topic in
the Transport area. Diffserv and Intserv were both developed in
the Transport area. It's a shame if they aren't aware of this work.

    Brian

> .

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 09:08:29 +0200

Hi Charles, 

Please see inline.
Cheers,
Med

>De : Charles Eckel (eckelcu) [mailto:[email-masked]]
>Envoyé : jeudi 18 juillet 2013 22:07
>À : BOUCADAIR Mohamed OLNC/OLN; Reinaldo Penno (repenno); [email-masked]
>Objet : RE: [Int-area] FW: New Version Notification for draft-eckert-
>[cue] Agreed. This is what we describe as "Proxy originated information" in
>section 3.1.4.1 (http://tools.ietf.org/html/draft-eckert-intarea-flow-
>metadata-framework-01#section-3.1.4.1). Does this address your concern?

[Med] Yes and No. I would prefer if concrete deployment examples are discussed (e.g., managed CPE for instance).

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 09:57:44 +0200

Dear Toerless,

Please see inline. 

Cheers,
Med

>De : Toerless Eckert [mailto:[email-masked]]
>Envoyé : vendredi 19 juillet 2013 05:13
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Reinaldo Penno (repenno); Charles Eckel (eckelcu); [email-masked]
>> [Med] I'm more interested in this CPE flavor (managed CPE) since it
>avoids relying on applications to benefit from the added value of this
>approach. This is worth be discussed in the document too.
>

[Med] Section 3.1.4.1 as it is does not provide decent discussion of these deployment issues and considerations. Sketching the expected behavior of such intermediary functions would even be better. This applies also for the other deployment-related issues I listed in my initial e-mail.

>> [Med] The question is not whether a secure transport is used or not but
>to what extent the flow description is accurate (e.g., send fake flow
>description, systematically request treatment with higher priority, etc.).
>
[Med] this discussion about trust is worth to be elaborated further in the document. For sure, this point will be raised by others.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 19 Jul 2013 11:33:00 +0000

Hi Med,

I agree with you that we need to cover in more detail the managed CPE
deployments but I wonder if this is the best document to do it.

Maybe a use-cases draft based on very concrete scenarios would be best.

Thanks,

Reinaldo

On 7/19/13 4:57 AM, "[email-masked]"
<[email-masked]> wrote:

>[Med] Section 3.1.4.1 as it is does not provide decent discussion of
>these deployment issues and considerations. Sketching the expected
>behavior of such intermediary functions would even be better. This
>applies also for the other deployment-related issues I listed in my
>initial e-mail.
>
>>
>[Med] this discussion about trust is worth to be elaborated further in
>the document. For sure, this point will be raised by others.
>
>>Cheers
>>    Toerless

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 14:41:07 +0200

Hi Reinaldo,

IMHO, deployment considerations are key aspects if you want this model to fly. Having the material in one document is better (at least in early stages to socialize the proposed framework within IETF). 

Cheers,
Med

>Envoyé : vendredi 19 juillet 2013 13:33
>À : BOUCADAIR Mohamed OLNC/OLN; Toerless Eckert (eckert)
>Cc : Charles Eckel (eckelcu); [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Jul 2013 18:35:10 -0700

Brian,

Cheers
    Toerless

---

From: "George, Wes" <[email-masked]>
Date: Mon, 22 Jul 2013 16:18:04 -0400

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.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 23 Jul 2013 21:16:40 +0000

Hi George, 

Thanks for your comments. Please see inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of George, Wes
> Sent: Monday, July 22, 2013 1:18 PM
> To: [email-masked]
> Subject: Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-
> 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

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

---

From: "Amine Choukir (amchouki)" <[email-masked]>
Date: Wed, 24 Jul 2013 08:38:31 +0000

Hello MED,

Thank you for the comments.

See answer inline.

On Jul 18, 2013, at 11:13 AM, <[email-masked]<mailto:[email-masked]>>
 wrote:

Dear Charles, all,

[AC ]We can definitely integrate a first set of use cases that help in understanding the value of flow characterisation to the network and who plays a role in producing those characteristics. I think we should both include SP and enterprise use cases as the question of trust in those two environments are solved in different ways. We did not include a draft on how to secure the flow characteristics as we felt more discussion was needed to get to a solid proposal including the aspect of single, multi-domain and transport specific vs transport independent security.

In the framework and the encoding we envisioned being able to signal from both endpoints and/or network elements (potentially more than one).

[AC] As Charles mentioned application can opt to use or not metadata and will still work as before if they don't. What the application gain is accuracy and granularity in terms of the characterisation of its flows for differentiated treatment and visibility.

[AC] The encoding we discuss is transport independent that it is why it is referenced in the framework. The way we would like to present how flow characterisation works is shown below. The framework as you said defines the information model and the use cases. The encoding draft defines how to encode in a transport independent way tags signalled by applications and/or network elements. The transport specific draft maps the framework and the encoding to the protocol specific logic and messaging. The security draft would be meant to cover transport independent security but this is to be discussed.

Hope that clarifies some of your concerns.

Cheers

Amine

                               +-----------------------------+
      +---------------------+  |  +----------------------+   |
      |                     |  |  |                      |   |
      |                     |  |  |                      |   |
      |                     |  |  |                      |   |
      |  security           +--+  |  framework           |   |
      |                     |  |  |                      |   |
      |                     |  |  |                      |   |
      |                     |  |  |                      |   |
      +---------------------+  |  +----------------------+   |
                               |                             |
                               |                             |
                               |  +----------------------+   |
                               |  |                      |   |
                               |  |                      |   |
                               |  |                      |   |
                               |  |   encoding           |   |
                               |  |                      |   |
                               |  |                      |   |
                               |  +----------------------+   |
                               ++------------+--------------++
      +----------------------+  | +----------+-----------+  | +-----------------------+
      |                      |  | |                      |  | |                       |
      |                      |  | |                      |  | |                       |
      |  STUN                +--+ |    PCP               |  +-+    RSVP               |
      |                      |    |                      |    |                       |
      |                      |    |                      |    |                       |
      +----------------------+    +----------------------+    +-----------------------+

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la
part de Charles Eckel (eckelcu)
Envoyé : lundi 15 juillet 2013 23:07
À : [email-masked]<mailto:[email-masked]>
Objet : [Int-area] FW: New Version Notification for draft-eckert-intarea-
flow-metadata-framework-01.txt

Cheers,
Charles

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 15, 2013 1:41 PM
To: Toerless Eckert (eckert); Amine Choukir (amchouki); Reinaldo Penno
(repenno); Charles Eckel (eckelcu)
Subject: New Version Notification for draft-eckert-intarea-flow-metadata-
framework-01.txt

Filename: draft-eckert-intarea-flow-metadata-framework
Revision: 01
Title: A Framework for Signaling Flow Characteristics between
Applications and the Network
Creation date: 2013-07-15
Group: Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-eckert-intarea-
flow-metadata-framework-01.txt
Status:          http://datatracker.ietf.org/doc/draft-eckert-intarea-flow-
metadata-framework
Htmlized:        http://tools.ietf.org/html/draft-eckert-intarea-flow-
metadata-framework-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-eckert-intarea-
flow-metadata-framework-01

Abstract:

The IETF Secretariat

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Amine Choukir (amchouki)" <[email-masked]>
Date: Wed, 24 Jul 2013 08:41:41 +0000

Hello Brian,

As Toerless mentioned the framework covers more than the QoS use case. Other use cases are for example visibility and differentiated routing.

We would definitely like to present this work in TSV as it has definitely some ties there.

Cheers

Amine
On Jul 18, 2013, at 9:58 PM, Brian E Carpenter <[email-masked]>