Re: [RRG] Commetns about load split in LISP

[Dino Farinacci <dino@cisco.com>]

> Hello,

Damian, thanks for your comments. Sorry for the delay on this  
response. See comments inline.

> In draft-farinacci-lisp-08, section 6.4, there are two things that  
> in my
> opinion require improvement and/or clarification:
>
> 1)
> In the load split algorithm proposed, a hash is used to select a  
> RLOC and it
> says "Either a source and destination address hash can be used or the
> traditional 5-tuple...". This has important impact in the load split  
> scheme:
> if you use only the source IP you are eventually limiting the rate  
> of a
> source (and other unlucky hash collisions), if you use the  
> destination IP
> you will limit the rate to a destination (and unlucky collisioners),  
> if you
> use the 5-tuple (or at least both IPs and ports) you are adopting  
> some kind
> of flow (un)fairness... Maybe this requires clarification.

That is not what is being stated. There are two types of hashes:

1) (source-address, destination-address) hash.
2) (source-address, destinatino-address, ip-protocol-number, source- 
port, dest-port) when the ip-protocol-number is TCP or UDP.

The reason this is stated is because many core routers will only do  
hash 1) when the IP protocol number is not TCP or UDP. When it is,  
hash 2) is used.

These algorithms are well-known and have been used for a long time.  
Please suggest text you feel would make this more clear. I think it's  
as clear as it can be.

> 2)
> About the selection of a random source UDP port for core routers  
> with LGAs
> to load balance (in the same section), as the draft says, if core  
> routers
> see a single flow they don't split-load. Random port selection would  
> make
> those routers to "break" flows, but they don't want to do that, is  
> that
> because they know it's not good?
> I think the random selection could be changed for a hash as in the  
> case
> mentioned above (and maybe unify the criteria about which part of the
> 5-tuple to use). This may be a must if: there are core routers
> load-splitting between links with different characteristics or there  
> are
> layer 3 load balancers choosing different paths (maybe even a  
> recursive LISP
> re-tunneling). In these cases the flows can get very damaged (poor RTT
> estimation, serious reordering, etc.)

That is what has been implemented. That is the ITR selects a source  
port number by doing a 5-tuple hash (or a {source-address, destination- 
address hash) on the inner header.

I will make this more clear in the spec.

> I hope my comments could be useful. All feedback is welcome. Thanks.

Yes they are. Thanks for your input.

> Regards,
> Damian Lezama

Dino


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg