Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Philip Homburg <[e-mail]>
> To: V6 Ops List <[e-mail]>
> Cc: 
> Sent: Tuesday, 3 June 2014 2:28 AM
> Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]
> 
> In your letter dated Mon, 02 Jun 2014 09:11:40 +1000 you wrote:
>> Every piece of client software should already support multi-homing.
>> This is about supporting it *better* so there isn't the big delay
>> when switching to the second address because the link at the other
>> end is down.  The stack should be choosing source addresses which
>> have working outbound paths.  Selecting destination addresses is
>> up to the application.
>> 
>> This is about making the error cases work better which quite frankly
>> should have been done years ago for IPv4.  The only ones that don't
>> benefit from this is GLB developers.
> 
> I'd like to see IPv6 deployed sooner rather than later. And in my 
> experience,
> everywhere where IPv6 is different from IPv4 it causes problems and extra
> delays.
> 

So if IPv6 was no different to IPv4 ... it'd be IPv4. So naturally, no matter how similar or different to IPv4 IPv6 was made, there was always going to be additional complexity when deploying it in parallel with IPv4.

> So if you say 'every piece of client software should already support

> multi-homing' then that is simply not true in the IPv4 world. At least while
> giving reasonable performance.
> 

I think that is actually an observation on how ubiquitous, reliable and reliably operated IPv4 is. The parallel HE approach clearly makes just as much sense for IPv4 instead of attempting each A RR IPv4 address sequentially after a timeout.

In some ways the it is surprising that the HE approach hasn't be necessary under IPv4. Google seem to consider that they need to facilitate IPv4 redundancy in this way, as a query for A records for google.com returns 16 different A records. I doubt they'd be doing that unless they had some evidence that it is useful to some portion of end-users. They are shuffling the addresses around on each query, however they could do that but still only return one.


Another way to think of the HE technique is that it is a variation of recovery from TCP SYN packet loss. Traditional recovery took place "horizontally", within a single TCP connection. HE recovery is taking place "vertically", across multiple different TCP connections (and possibly different layer 3 protocols.)

> If all IPv4 software supported multi-homing properly, then there was no need 
> for happy eyeballs. And many of the features that discussed in the context
> of happy eyeballs were not implemented in a large scale before.
> 
> As a result, there also no standard API for doing HE. The Berkeley socket
> interface is still the same because in practice, eveybody is not doing
> multi-homed. 
> 
> Doing HE with minimal overhead is very tricky. It is very easy for most
> client systems to take a full matrix of source and destination addresses and
> connect to all of them. I'm quite sure that most operators of server systems
> would completely hate that approach.
> 

So I think if you made them think about it, they'd probably change their mind. The servers exist to serve, and therefore anything that provides better service to the clients is certainly worth considering, if not implementing. They will consequently earn a reputation as being a reliable and high performing server operator.

They might probably also want to consider Multipath TCP at the same time, for the same reasons - better server/service performance and reliability. HE + MPTCP would provide more of both.



> Simply put, the more things we come up with that have to be done before someone
> can deplay IPv6, the longer it will take.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>