Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt

From: "Smith, Mark" <[email-masked]>
Date: Thu, 15 Nov 2001 08:31:53 +0800

Hi All,

While I haven't read Bob's draft, so my comments may be naive, but RFC 2991
"Multipath Issues in Unicast and Multicast Next-Hop Selection" seems to
recommend against round robin loadsharing, and arguably recommend against
per packet load sharing at all.

While the RFC is about routers performing the loadsharing over multiple
paths, I would think the issues it raises would probably also apply to
hosts.

Regards,
Mark.

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Thursday, 15 November 2001 11:05
> To: Christian Huitema
> Cc: [email-masked]
> Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt
> 
> 
> Christian,
> 
> >Even if we wanted to somehow mandate load sharing, there are 
> generally
> >issues with mandating a round robin approach, or in fact any specific
> >algorithm. Round robin has two drawbacks: it hypothesizes that all
> >routers are equal, which is very often not the case, and it 
> implies some
> >explicit ordering of the requests, which can lead to 
> synchronizations.
> >The all routers equal hypothesis is fine for dumb hosts, but 
> smart hosts
> >can acquire a knowledge that this or that router usually performs
> >better, which is enough to justify a "SHOULD" instead of 
> "MUST". The way
> >to avoid synchronization is normally randomization, i.e. 
> pick routers in
> >a random order rather than doing round robin.
> 
> The issue of all routers not being equal is a generic 
> neighbor discovery 
> issue.  Currently a host will add to it's default router list 
> any router it 
> receives routing advertisements.  Rich Draves "Default Router 
> Preferences 
> and More-Specific Routers" draft addresses this issue and 
> allows a ranking 
> of the default routers.
> 
> I think load sharing has value when there are multiple (equal 
> preference) 
> default routers.  It is very common in the IPv4 world for 
> people to set up 
> parallel paths with two or more routers.  In this case it is 
> useful for 
> hosts to spread their traffic among these routers.
> 
> I will revise the draft to change from round-robin to random 
> order to avoid 
> synchronization, and also change it from a MUST to a SHOULD 
> to allow for 
> hosts with more information.
> 
> Also, it may make sense to later combine this with Rich's 
> draft as they are 
> both dealing with related default router selection issues.  
> In this case 
> the load sharing would be done when there are multiple 
> default routers with 
> equal preference.
> 
> Bob
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Nov 2001 16:49:41 -0800

Mark,

>While I haven't read Bob's draft, so my comments may be naive, but RFC 2991

Yes, please read the draft!

>per packet load sharing at all.

The load sharing being proposed here in not per packet.  It is invoked when 
the host needs to send traffic to a destination it has not sent to recently 
(i.e., when no destination cache entry exists for an off-link 
destination).  This destination approach is part of Neighbor Discover 
(RFC2461).

>paths, I would think the issues it raises would probably also apply to

The issues are similar.  Load sharing approaches that don't keep flows 
together are not a good thing.

Bob