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

[Hesham Soliman <[e-mail]>]

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

=> great.

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

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

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

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

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

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

Hesham


> 
> Kind regards,
> Asanga
> 
> 
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Hesham Soliman
>> Sent: 14 November 2008 23:55
>> To: Umar Toseef; [e-mail]
>> Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments
>> 
>> Thanks for the review. A comment below.
>> 
>>> 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.
>> 
>> => 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 :).
>> 
>>> 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.
>> 
>> => I have to  agree with Stuart's comment here. Lower layers have nothing
>> to
>> do with this. This is an e2e feature.
>> 
>> Hesham
>> 
>>> Have a nice weekend,
>>> Kind Regards,
>> 
>> 
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
> 


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