Subject: Re: [MEXT] flow binding draft 3

From: Christian Kaas-Petersen <[email-masked]>
Date: Thu, 16 Jul 2009 10:43:37 +0000 (GMT)

I agree to reuse as much as possible.  The RFC 2460 definition says
a flow is from a specific source.  However, the first entry in the 
Ordered Flow Binding table of section 4.4 describes a flow as TCP
packets from any source, not a specific source.  So I don't think
the RFC 2460 definition fully covers the needs for flow bindings.
Also, is it the source which desires special handling of its IP
packets?  To me it more the destination having requested a special
handling to be performed by an intermediate node, the home agent
(for now I have ignored correspondent nodes and hierarchical mobility). 

Christian

--- Den tors 16/7/09 skrev Hesham Soliman <[email-masked]>:

Fra: Hesham Soliman <[email-masked]>
Emne: Re: [MEXT] flow binding draft 3
Til: "Christian Kaas-Petersen" <[email-masked]>, [email-masked]
Dato: torsdag 16. juli 2009 11.20

On 16/07/09 7:09 PM, "Christian Kaas-Petersen" <[email-masked]>
wrote:

> 
>  * chapter 3: After reading the document, I think a flow should be
>    defined as follows.  "Flow: A flow is a subset of all IP packets
>    sent *to* a mobile node.  The packets of the subset match
>    a flow description."  With this definition, it makes more sense
>    that a flow description can use source address, will never use
>    destination address, and can use both source and destination ports.

=> I actually prefer RFC 2460's definition:
   A flow is a sequence of packets sent from a particular source to a
   particular (unicast or multicast) destination for which the source
   desires special handling by the intervening routers

I think we should reuse it as much as possible.

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 16 Jul 2009 20:59:01 +1000

> the RFC 2460 definition fully covers the needs for flow bindings.

=> Sure but it's essentially a wildcard tool that translates to any src. If
it makes it easier we can simply s/particular/a. I don't see an issue with
that. 

> (for now I have ignored correspondent nodes and hierarchical mobility).

=> I don't think you should ignore CNs and HMIP. Regardless of who's
requesting the treatment of the flow, the definition of a flow should be
orthogonal to the scenario in which it is used. For example, we don't say
that the FID is a number located in the third byte of the option, we just
say it's a number. 

Hesham

>       Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på
> LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 21 Jul 2009 11:40:25 -0700

Hesham & Christian:

> it makes it easier we can simply s/particular/a. I don't see an issue with

I realize it's a bit late, but in light of this discussion, given the
flow definition of RFC 2460, and given the mechanism we want to
provide, namely, "extensions to Mobile IPv6 that allow nodes to bind
one or more flows to a care-of address",  I'm feeling that most of the
time when the draft refers to a "flow" it should instead refer to a
"flow aggregate" because multiple RFC 2460 "flows" can correspond to a
single "flow descriptor", as Christian has pointed out with the TCP
example.

A less important thing is the use of "descriptor" which, while not
necessarily incorrect, has been quite often used as a number pointing
to an item in a repository, in a similar fashion to identifier. I was
thinking that "selector" might be more appropriate...

In light of this, I'm now wondering whether the terminology would be
more consistent if we'd refer to RFC 2460 for the definition of a flow
and renamed throughout the ID:

- flow => flow aggregate
- flow descriptor => flow aggregate selector
- flow ID => flow aggregate ID / flow aggregate descriptor

What do you think?

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Jul 2009 11:33:05 +1000

> - flow ID => flow aggregate ID / flow aggregate descriptor

=> I'm wondering whether we would have to always write "flow or flow
aggregate" in the doc because it's not always about a bunch of flows.
Alternatively, if we don't define a flow as being from a single source, then
we can just use "flow". I don't have a problem with the other two terms you
suggest above. 

Hesham

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 21 Jul 2009 20:39:47 -0700

> Hesham Soliman <[email-masked]> wrote:
> 
> Alternatively, if we don't define a flow as being from a single source,
> then we can just use "flow". I don't have a problem with the other two terms
> you suggest above.

I think we should stick to RFC 2460 for the definition of a flow, i.e., "a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers."

After thinking a bit more to the term "aggregate", I do not think anymore that "flow aggregate" is a good term because in a situation where we have a traffic selector that matches all HTTP flows (i.e., proto tcp port 80), it's likely that the traffic is disaggregated since every flow goes to a different web server.

How about we use "flow" in the sense of 2460 and its plural form where required, and "traffic selector" and "traffic selector descriptor/ID" where talking about the object that matches a bunch of "flows", and the reference to it?

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 22 Jul 2009 13:44:09 +1000

> I think we should stick to RFC 2460 for the definition of a flow, i.e., "a
> sequence of packets sent from a particular source to a particular (unicast or
> multicast) destination for which the source desires special handling by the
> intervening routers."
>
=> Agreed.
> 
> After thinking a bit more to the term "aggregate", I do not think anymore that
> "flow aggregate" is a good term because in a situation where we have a traffic
> selector that matches all HTTP flows (i.e., proto tcp port 80), it's likely
> that the traffic is disaggregated since every flow goes to a different web
> server.

=> Yes.

> 
> How about we use "flow" in the sense of 2460 and its plural form where
> required, 

=> Right, or we can say somewhere early in the doc that we will use the word
"flow" to indicate the singular and plural.

and "traffic selector" and "traffic selector descriptor/ID" where
> talking about the object that matches a bunch of "flows", and the reference to
> it?

=> I'm ok with that.

Hesham

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 22 Jul 2009 12:12:12 -0700

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]]
> Sent: Tuesday, July 21, 2009 8:44 PM
> To: Laganier, Julien
> Cc: Christian Kaas-Petersen; [email-masked]
> Subject: Re: [MEXT] flow binding draft 3
> 
> 
> >>
> > I think we should stick to RFC 2460 for the definition of a flow,
> > i.e., "a sequence of packets sent from a particular source to a 
> > particular (unicast or multicast) destination for which the 
> > source desires special handling by the intervening routers."
> 
> => Agreed.
> 
> > After thinking a bit more to the term "aggregate", I do not think
> > anymore that "flow aggregate" is a good term because
> > in a situation where we have a traffic selector that matches all 
> > HTTP flows (i.e., proto tcp port 80), it's likely
> > that the traffic is disaggregated since every flow goes to a
> > different web server.
> 
> => Yes.
> 
> > How about we use "flow" in the sense of 2460 and its plural form
> > where required,
> 
> => Right, or we can say somewhere early in the doc that we will use the
> word "flow" to indicate the singular and plural.

I think easiest is to use "flow" when we talk about one, "flows" when we talk about more than one, and "flow(s)" where we talk about one or more flow(s).
 
> > talking about the object that matches a bunch of "flows", and the

All right then.

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Jul 2009 13:20:39 +1000

Sorry I got distracted by a few things and forgot to reply earlier. Yes I'm
fine with your suggestion about the use of "flow(s)".

Hesham

On 23/07/09 5:12 AM, "Laganier, Julien" <[email-masked]> wrote:

> I think easiest is to use "flow" when we talk about one, "flows" when we talk
> about more than one, and "flow(s)" where we talk about one or more flow(s).
>

---

From: Frank Xia <[email-masked]>
Date: Thu, 23 Jul 2009 12:31:23 -0400

Hi Hesham

IMHO, we, IETF partipants, play by rules which
are documented in charters.

The whole arguments back and forth are just
because of the ambiguious charter.

BR
Frank

----- Original Message ----- 
From: "Hesham Soliman" <[email-masked]>
To: "Laganier, Julien" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 22, 2009 11:20 PM
Subject: Re: [MEXT] flow binding draft 3

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext