Subject: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments

From: Umar Toseef <[email-masked]>
Date: Fri, 14 Nov 2008 15:53:20 +0100

Hello Everybody,
I just went through the draft-ietf-mext-flow-binding-00.txt while 
previously I implemented the basic functionaliy of 
draft-soliman-monami6-flow-binding. It's good to see that based on the 
demands of reviewers authors have excluded the flow description part 
from the flow binding mechanism. Of course it offers more flexibility to 
those who want to use flow bindings with their custom way of flow 
description. However I have two comments on this draft. First of all, 
while implementing draft-soliman-monami6-flow-binding I realized that 
prioritizing flow bindings creates a lot of complexity when it comes to 
managing the flows. For example sender has to determine the overlaps and 
specify correct priority of each flow binding and similarly the receiver 
will also be taking care of priorities while installing the filters. 
This situation gets worse as number of flow bindings grows. In my 
opinion leaving priority out and using chronological order of filters at 
the receiving end will make things more simple and easy for practical use.
Secondly, I am not a fan  of n-casting option. Such mechanisms of 
diversity work better at lower layers therefore when lower layers are 
already making use of diversity then redoing it at network layer does 
seems very attractive to me.
However these are just opinions from my side and i invite other working 
group members to comment on it.
Have a nice weekend,
Kind Regards,

-- 

-----------------------------------------------------------------
Umar Toseef                 IKOM/ComNets -- FB 1
Research Engineer           University of Bremen
Tel: +49 421 218-8665       Otto-Hahn-Allee 1
Fax: +49 421 218-3601       28359 Bremen

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

---

From: "Stuart W. Card" <[email-masked]>
Date: Fri, 14 Nov 2008 17:03:14 -0500 (EST)

Umar Toseef <[email-masked]> wrote --

> ... draft-ietf-mext-flow-binding-00.txt...
> I am not a fan of n-casting option.
> Such mechanisms of diversity work better at lower layers
> ... redoing it at network layer...

Lower layers can only do it if we are balancing/coding across _links_.
It is necessary to do it in the Network or Transport layer if we
are balancing/coding across _paths_. The latter is more general
and subsumes the former. It is central to my team's work. We are
hoping that the flow binding work will give us a standards based
mechanism for some elements of this. 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: Hesham Soliman <[email-masked]>
Date: Sat, 15 Nov 2008 09:55:08 +1100

Thanks for the review. A comment below.

> the receiving end will make things more simple and easy for practical use.

=> I think we need to be careful when we discuss features in terms of
"simple" and "complex". You need to look at what you lose to make it simple
to implement. In this case you lose a major function that handles overlaps.
This is fundamental to any filtering. It's ok to have complex algorithms,
it's not like the user will know anything. If we didn't have complex
features there would be no google :).

> group members to comment on it.

=> I have to  agree with Stuart's comment here. Lower layers have nothing to
do with this. This is an e2e feature.

Hesham

---

From: "Asanga Udugama" <[email-masked]>
Date: Mon, 17 Nov 2008 11:13:59 +0100

Hello all,

I too have a lot of experience in using the implementation done by Umar of
the draft-soliman-monami6-flow-binding. In my opinion, I believe that this
is a very clear and a simple draft, which follows the KISS principle.
 
Some time back, I too implemented a similar flow management draft on MIPv4.
It was done on the Sun Labs MIPv4 and it was called NOMAD. Similar to Umar's
implementation, it too used the packet marking and multiple routing table
features available in Linux. When I did this implementation, there were
other simple features that were present in it compared to this draft. I
would like to ask the authors, why these have been removed. Was there any
reason to leave these out? 2 of these are,

1) Splitting flows - Meaning that the packets of a single flow are placed on
different attachments. I know that TCP would perform adversely but some UDP
based applications may perform better. Further, the draft that I implemented
also allowed the specification of the packet distribution ration, which I
found very interesting as then, the ratio can be optimally decided to cater
to the different characteristics of the network attachments

2) Free-form filters - Meaning that we could set filters based on any part
of the packet, rather than only the headers. I know that this may not be
possible when the payload is encrypted. But still there maybe instances when
pattern matching maybe done on the payload to identify a flow.

Kind regards,
Asanga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hesham Soliman
> Sent: 14 November 2008 23:55
> To: Umar Toseef; [email-masked]
> Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments
>

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 17 Nov 2008 15:45:42 -0500

Asanga Udugama wrote:
> ...
> to the different characteristics of the network attachments...
There are interoperable, standards-compliant, extended TCP variants that 
can handle this just fine.
We use the Space Communications Protocol Standards - Transport Protocol 
(SCPS-TP).
Because it uses Selective Negative Acknowledgments (SNACKs), it can 
handle out-of-order delivery.
Admittedly, we had to suggest a SNACK timer extension to the CCSDS 
(which they standardized).

We have successfully load-balanced a single TCP flow over 2 paths with 
an 8:1 bandwidth ratio.
We could probably handle higher ratios but haven't felt it worthwhile 
(little additional performance).
We have also successfully balanced over 3 or more (can't remember how 
many) concurrent paths.

This has not only been extensively tested in our and independent 3rd 
party labs --
it is also in mission-critical field use by a U.S. military service for 
whom we integrated it.

It would be prudent to have control over which flows get what kind of 
load balancing:
some application and transport protocols can handle (and benefit from) 
packet-by-packet;
most can handle (and benefit from) flow-by-flow; others neither (these 
last are rare).
This control isn't really a MEXT issue: it can be handled with DiffServ, 
for instance.

A Hybrid Type II ARQ/FEC transport protocol should perform even better 
-- stay tuned! :-)

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 18 Nov 2008 15:58:17 +1100

> is a very clear and a simple draft, which follows the KISS principle.

=> great.

> reason to leave these out? 2 of these are,

=> We didn't remove anything from our draft, perhaps you're asking why we
didn't include some of the features in nomad.

> to the different characteristics of the network attachments

=> We felt that this is not a good idea for multiple reasons:
- As you said, most TCP implementations deployed would struggle with this
and it can have negative impacts. In fact, there are several recommendations
by traffic engineers to avoid this sort of thing.
- the paths can be very diverse in terms of delays.
- Secure traffic would fail in this scenario. In many cases you don't know
if the traffic will be secure or not. This applies to UDP traffic too.

> pattern matching maybe done on the payload to identify a flow.

=> Filters are not included in this draft at all. The WG decided to do this
in a separate draft.

Hesham

---

From: Conny Larsson <[email-masked]>
Date: Tue, 18 Nov 2008 13:27:01 -0600

Hi Asanga,

Hesham Soliman wrote:
[snip]
> => Filters are not included in this draft at all. The WG decided to do this
And the draft describing how this can be done is 
http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt

Regards
Conny
>>>> the receiving end will make things more simple and easy for practical
>>>>         
>>> use.
>>>

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 18 Nov 2008 16:26:04 -0500 (EST)

[email-masked] wrote --

>> => Filters are not included in this draft at all. The WG decided to do
>> this in a separate draft.

[email-masked] wrote --

> http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt

I hadn't reviewed the latter draft before.
Thank you for pointing it out.
It looks like it may become very useful in my team's work.
My comments follow.

>From that draft:

> 5.4.  Conditional Rule-Sets
>
>   For some scenarios, it is useful to install or transmit a collection
>   of rule-sets at the same time, and select which one to use depending
>   on what PIDs are available.  How the set of available PIDs is
>   determined is outside the scope of this document.

and:

> 5.14.  Round-robin
>
>   For load-sharing purposes, round-robin transmission is supported.  To
>   use round-robin, a list of PIDs is given instead of just one:
>
>      udp peer 2001:db8:1c32::/48 port 44100 on 4, 4, 5
>
>   Here, UDP traffic from port 44100 at any node in prefix 2001:db8:
>   1c32::/48 will be sent on PIDs 4 and 5.  Two out of three packets
>   will go on PID 4, which presumably has twice the bandwidth of PID 5.

These specs make sense iff:
 a PID is either available, or not; and
 coarse granularity in bandwidth allocation is adequate.

However, a path may be 'available', but currently degraded.
Or paths may simply have bandwidth that is highly variable.
Likewise different paths may have slightly different bandwidths.

In bandwidth constrained mobile wireless environments,
I don't want to fail to use a path at all,
just because it is degraded somewhat at the moment;
but neither can I pump its full normal load of packets.

What is needed is recognition that a path may be
neither simply 'up' nor simply 'down', but in between
(see IEEE 802.21 work, which starts to recognize this).

Conditionals need to be able to consider quantitative thresholds.
It would be even nicer if rules could be fuzzy,
with grades of predicate truth and consequent rule firing activity,
but that may be asking too much at this stage.

Likewise variables that can pass capability information are needed.
Then if I have PID 1 and PID 2, each of which is nominally 10 Mbps:

 if both are performing nominally, I want to balance 50%:50%;

 if PID 2 is completely down, I want to balance 100%:0%; and

 if PID 1 is running half its normal rate, I want to balance 33%:67%.

Does anyone else out there have an interest in such subtle variations:
between capabilities of different paths at the same time;
and of the capabilities of a single path over time?

We have actually been doing this for some time,
but in a proprietary way; I would like to generalize it
and base it on open standards.

Thanks all!

---

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

> Likewise different paths may have slightly different bandwidths.

At the Home Agent, a path can only be "available" or "not available",
as it is determined by if a particular BID is bound or not
(draft-larsson PIDs map directly to MIPv6 BIDs).

If the availability is "fuzzy" (sometimes degraded), that would have
to be handled by some outside party that updates the flow rules at the
HA (and MN) according to the conditions of each path.

BR, Michael