Subject: [MEXT] Flow description in draft-ietf-mext-flow-binding

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 18 Nov 2008 22:27:23 -0800

Hi all,

the current version of draft-ietf-mext-flow-binding does not specify any type of flow description and leaves to other documents how to specify the filters which are installed by the UE at the HA. 

I think we should add a basic version of the Flow Description in this draft to support filters in binary form (5-tuples). We have already one draft for MCoA and one for Flow Binding which will very often be used together and are part of the same multihoming solution; adding yet another separate draft will have bad impacts on the readability of the specifications.

Moreover the flow binding draft was scheduled to be sent to IESG October 2008 but we have not gone through the WGLC yet. This is the right time to add the Flow Description in this draft without adding much delay; waiting for another draft to be published may delay the work too much. 

I think the support of binary description of the filters is pretty straighforward and very well known in IETF. This seems to be also the most reasonable solution in cellular networks where we may want to save bandwidth. Obviously the FID optoin will still be Flow Description agnostic and other more sophisticated Filter Description can be defined in separate documents. 

What do people think? Chairs?

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

---

From: "Stuart W. Card" <[email-masked]>
Date: Wed, 19 Nov 2008 13:25:07 -0500 (EST)

> ...
> I think the support of binary description of the filters is pretty
> straighforward and very well known in IETF. This seems to be also the
> most reasonable solution in cellular networks where we may want to save
> bandwidth...

I often have to deal with _really_ slow media (2400 bps,
half-duplex, with > 250 mS receive-transmit turnaround).
So I have a great appreciation for efficient encodings.

That said, I believe that generality, flexibility and
extensibility are more important to overall efficiency
than are the few dozen or even couple hundred bytes that
are saved every few seconds or minutes by encoding
flow descriptions in binary.

So my point is, if we are confident that we can specify
a general, flexible, extensible, binary flow description
language, great... but I'd rather stick with inefficient
ASCII encodings if aren't yet to the maturity level in
our understanding of this problem that we can retain
those essential characteristics in a binary encoding.

Sorry to bore you all with fuzzy philosophical ramblings
but I think the long- versus short-term efficiency tradeoff
is point that should not be forgotten. Thanks!

-- 
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> www.critical.com

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 19 Nov 2008 10:48:44 -0800

I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. 

What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work.

Gerardo

> -----Original Message-----
> From: Stuart W. Card [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2008 10:25 AM
> To: Giaretta, Gerardo
> Cc: [email-masked]
> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding
> 
> 
> > ...

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 20 Nov 2008 06:00:05 +1100

I don't have a problem adding it Gerardo if people are happy with that.

Hesham

On 19/11/08 5:27 PM, "Giaretta, Gerardo" <[email-masked]> wrote:

> Hi all,
> 
> the current version of draft-ietf-mext-flow-binding does not specify any type
> of flow description and leaves to other documents how to specify the filters
> which are installed by the UE at the HA.
> 
> I think we should add a basic version of the Flow Description in this draft to
> support filters in binary form (5-tuples). We have already one draft for MCoA
> and one for Flow Binding which will very often be used together and are part
> of the same multihoming solution; adding yet another separate draft will have
> bad impacts on the readability of the specifications.
> 
> Moreover the flow binding draft was scheduled to be sent to IESG October 2008
> but we have not gone through the WGLC yet. This is the right time to add the
> Flow Description in this draft without adding much delay; waiting for another
> draft to be published may delay the work too much.
> 
> straighforward and very well known in IETF. This seems to be also the most
> reasonable solution in cellular networks where we may want to save bandwidth.
> Obviously the FID optoin will still be Flow Description agnostic and other
> more sophisticated Filter Description can be defined in separate documents.
>

---

From: Conny Larsson <[email-masked]>
Date: Wed, 19 Nov 2008 13:25:38 -0600

Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement 
since I have not implemented any of the solutions (binary 
encoding/ASCII-based encoding). However, one of my colleagues has made 
an implementation of the ASCII-based solution, as specified in 
http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, 
and according to him it was easy to implement and caused no major 
problems. We even have a prototype on Linux up and running and it works 
perfectly well for distributing flows simultaneously among three 
different interfaces.

You are saying "What I would like to avoid is to not have any of those 
in the current draft. At least one of these should be specified in the 
base draft in order to have a complete solution.". Could you please 
elaborate a little bit more why you think 
draft-larsson-mext-flow-distribution-rules would not do the work 
sufficiently?

My proposal is of course to specify a reference to draft-larsson and get 
a flexible solution from the beginning.

Regards
Conny

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 19 Nov 2008 13:15:17 -0800

Hi Conny,

I think the point is that binary encoding is more bandwidth efficient. If we consider 3GPP as an example, the binary encoding is used for QoS reservations and requests. In my view we could use a similar binary encoding also for flow mobility and document that in the basic draft.

I see the argument of flexibility but this comes to a cost. Pointing to draft-larsson for more flexible encoding is fine to me but I don't think that should be the basic model.

Cheers
Gerardo

From: Conny Larsson [mailto:[email-masked]]
Sent: Wednesday, November 19, 2008 11:26 AM
To: Giaretta, Gerardo
Cc: [email-masked]; [email-masked]
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement since I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, and according to him it was easy to implement and caused no major problems. We even have a prototype on Linux up and running and it works perfectly well for distributing flows simultaneously among three different interfaces.

You are saying "What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules would not do the work sufficiently?

My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning.

Regards
Conny

Giaretta, Gerardo wrote:

Gerardo

-----Original Message-----

To: Giaretta, Gerardo

Cc: [email-masked]<mailto:[email-masked]>

...

bandwidth...

--

315-793-0248 x141 FAX -9710 <[email-masked]><mailto:[email-masked]> www.critical.com<http://www.critical.com>

MEXT mailing list

[email-masked]<mailto:[email-masked]>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 19 Nov 2008 15:21:56 -0600

Hi Gerardo,

The bandwidth efficiency of binary encoding is true in general.
However if you look at SIP for example, why did they choose to not specify
it with binary encoding?

There is value with the Ascii encoding model. I just don¹t know if there is
a need to be highly optimized here to choose the binary encoding format as
the default.

-Raj

On 11/19/08 3:15 PM, "Giaretta Gerardo" <[email-masked]> wrote:

> Hi Conny,
>  
> I think the point is that binary encoding is more bandwidth efficient. If we
> consider 3GPP as an example, the binary encoding is used for QoS reservations
> and requests. In my view we could use a similar binary encoding also for flow
> mobility and document that in the basic draft.
>  
> I see the argument of flexibility but this comes to a cost. Pointing to
> draft-larsson for more flexible encoding is fine to me but I don¹t think that
> should be the basic model.
>  
> Cheers
> Gerardo
>  
> 
> I have difficulties to comment on your flexibility/efficiency statement since
> I have not implemented any of the solutions (binary encoding/ASCII-based
> encoding). However, one of my colleagues has made an implementation of the
> ASCII-based solution, as specified in
> and according to him it was easy to implement and caused no major problems. We
> even have a prototype on Linux up and running and it works perfectly well for
> distributing flows simultaneously among three different interfaces.
> 
> You are saying "What I would like to avoid is to not have any of those in the
> current draft. At least one of these should be specified in the base draft in
> order to have a complete solution.". Could you please elaborate a little bit
> more why you think draft-larsson-mext-flow-distribution-rules would not do the
> work sufficiently?
> 
> I definitely agree with you on the importance of long term and flexible
> solutions. My point is that there are probably different scenarios with
> different requirements and in some of them it makes sense to use binary
> encoding (which is less flexible but more efficient) and in some other it
> makes sense to use ASCII-based encoding.
>  
> What I would like to avoid is to not have any of those in the current draft.
> At least one of these should be specified in the base draft in order to have a
> complete solution. I think we should go for the binary solution (which was
> originally part of the I-D indeed) as it requires less work and can be seen as
> the basic solution. In the meanwhile we can focus on an ASCII-based solution
> which is more flexible but would require some more work.
>  
> Gerardo
>  
>   
>> 315-793-0248 x141 FAX -9710 <[email-masked]>
>> <mailto:[email-masked]>  www.critical.com <http://www.critical.com>
>>  
>>  
>>     
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 19 Nov 2008 13:27:32 -0800

Hi Raj,

The point is that in some scenarios what the MN needs to communicate to the HA are simple 5-tuples, most of them may even contain wild-carded values. The amount and the details of information carried over SIP is different.

I am not proposing the binary encoding should be the default. I am saying it is simple enough to document it in the basic draft (we basically need one mobility option). I am fine if we move forward also draft-larsson at the same time and we include references in the flow binding draft.

Gerardo

From: Basavaraj Patil [mailto:[email-masked]]
Sent: Wednesday, November 19, 2008 1:22 PM
To: Giaretta, Gerardo; Conny Larsson
Cc: [email-masked]
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Gerardo,

The bandwidth efficiency of binary encoding is true in general.
However if you look at SIP for example, why did they choose to not specify it with binary encoding?

There is value with the Ascii encoding model. I just don't know if there is a need to be highly optimized here to choose the binary encoding format as the default.

-Raj

Cheers
Gerardo

Hi Gerardo,

Regards
Conny

Giaretta, Gerardo wrote:

Gerardo

-----Original Message-----
From: Stuart W. Card [mailto:[email-masked]]
Sent: Wednesday, November 19, 2008 10:25 AM
To: Giaretta, Gerardo
Cc: [email-masked]
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

...

--
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> <mailto:[email-masked]>  www.critical.com <http://www.critical.com>

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

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Thu, 20 Nov 2008 11:15:41 +0900

Hi Gerardo,

My understanding is that your point is use of simple 5-tuples as
flow description and transportation of binary encoded them for
saving bandwidth.

I think that this is one basic example for QoS reservations and
requests and is very simple. But this is not generic.

So, I propose to describe it in both documents (Flow binding and
Flow distribution) as one example for QoS reservations and requests.

For example, in flow binding document, we include that flow description
SHOULD be used binary encoded 5-tuples in case of QoS reservations and
resuests.
On the other hand, in flow destribution document, we define more generic 
  routing rules and include that the number of routing rules SHOULD be 
minimize (e.g. 5-tuples) in case of it.
Now, in flow destribution document, it is described that routing rules
could be stored in a file system in the ASCII form, but they could also
be stored in, e.g., in-core (binary) data structures.

What do you think this?

Regards,
Kazuyuki.

Giaretta, Gerardo Wrote:
> ------------------------------------------------------------------------
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 19 Nov 2008 21:50:01 -0800

Hi Kazuyuki,

I don't fully understand your proposal. I don't think we should mention QoS requests in the document; I used that as an example of how binary encoding is used in other SDO.

My proposal would be to specify a simple mobility option for binary encoding in draft-ietf-mext-flow-binding. The draft will state something like the following:

"The MN MAY use this binary encoding specified in this draft as Flow Description. Alternatively the MN MAY use the encoding specified in draft-larsson."

In this way we capture both solutions and we don't prioritize any of them.

Would that be acceptable?

Thanks
Gerardo

________________________________________
From: Kazuyuki Tasaka [[email-masked]]
Sent: Wednesday, November 19, 2008 6:15 PM
To: Giaretta, Gerardo
Cc: Basavaraj Patil; Conny Larsson; [email-masked]
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Gerardo,

What do you think this?

Regards,
Kazuyuki.

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Thu, 20 Nov 2008 18:51:52 +0900

Hi Gerardo,

I think that the flow description should be defined in another
document(e.g. draft-larsson). This is the WG decision.
On the other hand, I agree to specify one reference example
(e.g. example for binary encoding) in flow-binding.

So, "The MN MAY use the encoding specified in draft-larsson as flow 
description. At this time, the MN MAY handle not only data stored in
the ASCII form but also data stored in binary data structures for
saving bandwidth. In this case, MN SHULD use a mobility option for
binary encoding".

Regards,
Kazuyuki.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Nov 2008 09:29:58 -0800

Hi Kazuyuki,

I think what you are proposing is exactly the opposite of what I was proposing so I am not sure I can agree :-)

Let's see if others have any opinion. As I mentioned, I am fine documenting both scheme and make them optional, i.e. leave to the deployment which scheme to use. This may end up with some interop issues but it is also true that different deployments have different requirements. 

My point was just to document the binary scheme in the basic draft as it seems quite straightforward and easy to add to the draft (it was already there indeed). However I am also fine having a separate draft also for the binary scheme if this is what the WG prefers. 

Gerardo

> From: Kazuyuki Tasaka [mailto:[email-masked]]
> Sent: Thursday, November 20, 2008 1:52 AM
> To: Giaretta, Gerardo
> > I don't fully understand your proposal. I don't think we should mention QoS
> requests in the document; I used that as an example of how binary encoding is
> used in other SDO.
> >
> > My proposal would be to specify a simple mobility option for binary encoding
> in draft-ietf-mext-flow-binding. The draft will state something like the
> following:
> >
> > "The MN MAY use this binary encoding specified in this draft as Flow
> Description. Alternatively the MN MAY use the encoding specified in draft-
> larsson."
> >
> >> The point is that in some scenarios what the MN needs to communicate to the
> HA are simple 5-tuples, most of them may even contain wild-carded values. The
> amount and the details of information carried over SIP is different.
> >>
> >> I am not proposing the binary encoding should be the default. I am saying
> it is simple enough to document it in the basic draft (we basically need one
> mobility option). I am fine if we move forward also draft-larsson at the same
> time and we include references in the flow binding draft.
> >>
> >> Gerardo
> >>
> >> There is value with the Ascii encoding model. I just don't know if there is
> a need to be highly optimized here to choose the binary encoding format as the
> default.
> >>
> >> -Raj
> >>
> >>
> >> I think the point is that binary encoding is more bandwidth efficient. If
> we consider 3GPP as an example, the binary encoding is used for QoS
> reservations and requests. In my view we could use a similar binary encoding
> also for flow mobility and document that in the basic draft.
> >>
> draft-larsson for more flexible encoding is fine to me but I don't think that
> since I have not implemented any of the solutions (binary encoding/ASCII-based
> ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-
> mext-flow-distribution-rules-01.txt, and according to him it was easy to
> implement and caused no major problems. We even have a prototype on Linux up
> and running and it works perfectly well for distributing flows simultaneously
> among three different interfaces.
> >>
> >> You are saying "What I would like to avoid is to not have any of those in
> the current draft. At least one of these should be specified in the base draft
> in order to have a complete solution.". Could you please elaborate a little
> bit more why you think draft-larsson-mext-flow-distribution-rules would not do
> the work sufficiently?
> >>
> >> What I would like to avoid is to not have any of those in the current
> draft. At least one of these should be specified in the base draft in order to
> have a complete solution. I think we should go for the binary solution (which
> was originally part of the I-D indeed) as it requires less work and can be
> seen as the basic solution. In the meanwhile we can focus on an ASCII-based
> solution which is more flexible but would require some more work.
> >>
> >> Gerardo
> >>
> >>

---

From: Conny Larsson <[email-masked]>
Date: Thu, 20 Nov 2008 18:41:56 +0100

Hi Gerardo,

I'm in favour of having the flow description in separate documents. 
That's actually the reason for removing what was originally in Hesham's 
draft and making it a pure protocol for transferring those flow 
descriptions.

The drawback with having two schemes is of course that you have to agree 
upon which one to use and in the case you don't support it you need to 
inform the other side of the shortcomings. But this can probably be 
solved quite easy in Hesham's draft.

Regards
Conny

Giaretta, Gerardo wrote:
>>>> My proposal is of course to specify a reference to draft-larsson and get a
>>>>         
>> flexible solution from the beginning.
>>     
>>>> Regards
>>>> Conny
>>>>
>>>>
>>>> Giaretta, Gerardo wrote:

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Fri, 21 Nov 2008 07:16:11 +0900

Hi Gerardo,

> I think what you are proposing is exactly the opposite of what I was proposing so I am not sure I can agree :-)

I think so :-)

> My point was just to document the binary scheme in the basic draft as it seems quite straightforward and easy to add to the draft (it was already there indeed). However I am also fine having a sepa…

OK, let's see if others have any opinion.
By the result, I think we can make a final decision:
- We should have the flow description in separate documents.
   In this case, we will specify pure protocol for transferring flow
   descriptions in flow-binding document and flow descriptions in
   draft-larsson document as has been discussed in WG.
or
- We should have flow-binding document newly specified a basic binary
   encoding and a simple mobility option for it and draft-larsson
   document specifed routing rules as more generic flow descriptions.
or
- other opinion?

Regards,
Kazuyuki

---

From: Michael Eriksson <[email-masked]>
Date: Fri, 21 Nov 2008 15:04:27 +0100

On Tue, Nov 18, 2008 at 22:27:23 -0800, Giaretta, Gerardo wrote:
> the current version of draft-ietf-mext-flow-binding does not specify
> any type of flow description and leaves to other documents how to
> specify the filters which are installed by the UE at the HA.
> 
> I think we should add a basic version of the Flow Description in
> this draft to support filters in binary form (5-tuples). We have
> already one draft for MCoA and one for Flow Binding which will very
> often be used together and are part of the same multihoming
> solution; adding yet another separate draft will have bad impacts on
> the readability of the specifications.
> 
> Moreover the flow binding draft was scheduled to be sent to IESG
> October 2008 but we have not gone through the WGLC yet. This is the
> right time to add the Flow Description in this draft without adding
> much delay; waiting for another draft to be published may delay the
> work too much.
> 
> straighforward and very well known in IETF. This seems to be also
> the most reasonable solution in cellular networks where we may want
> to save bandwidth. Obviously the FID optoin will still be Flow
> Description agnostic and other more sophisticated Filter Description
> can be defined in separate documents.

I think that we should only use a free text (i.e., ASCII) format:

- It is much easier to generate (think printf).

- It is much easier to debug.

- It is probably also easier to parse; a binary format with optional
  fields (to save bytes) is prone to errors.

- In some cases, the rules will be static. Rules in text format can be
  written in a regular text editor and stored for later use. Storing
  binary rules are cumbersome at best.

- It is easier to make future extensions to a text format.

Having both a binary and a text format should be avoided, as it will
lead to interoperability problems and more implementation work.

We have already suggested a free text rule language, see
draft-larsson-mext-flow-distribution-rules. I suggest you read that,
and see if it doesn't solve your problems. Any feedback on the draft
is of course very welcome.

/Micke