Re: [arch-d] Development of Internet Protocol "Five Fields" (IP-FF): Presentation

[Bob Briscoe <[e-mail]>]

Alexy,

I suspect you are most proud of the fact that you have produced a set of 
ideas that all work well together.
But see inline...

On 05/01/16 20:56, Joe Touch wrote:
> On 1/5/2016 10:14 AM, Tony Li wrote:
>>>> On Jan 5, 2016, at 9:43 AM, Theodore V Faber<[e-mail]>  wrote:
>>>>
>>>> Let us know when you’ve implemented something.
>> … and when you’ve thought about the routing implications of your design.
> ...and when you have a plan for tech transition.
>
> It's very easy to redesign any protocol if you ignore the need to
> support legacy systems.

*1. Deployability**
*
...I would argue that the value of each part of FF has to be assessed as 
if that part was separate from the rest, for the reason Joe gives... 
...there is little mention or consideration of incremental deployability 
{note 1} of the whole system, let alone each of the parts (other than 
the NAT part).

But even though the FF system is unlikely to ever be deployable as a 
whole, it might be possible to modify some of the individual ideas in FF 
to add incremental deployability, so that the most valuable ideas can 
become usable individually.

*2. Private problem statement?**
*
The biggest problem with FF is that you have been working on solving a 
set of problems that few would agree have been articulated as the real 
underlying problem that needs to be solved. The problem statement is the 
part that should be done in public, even if you do the design in private.

* v6 address space too big - so what? it's more important to agree on 
any size, than to have the "right" size.
* v6 addresses hard to transliterate, read etc - so what? - just a tools 
problem
* mobility without breaking transport - need to solve this without 
compromising other features like ability to keep ports private. A number 
of alternative ways already solve this: multipath TCP, or Teemu Koponen 
et al's "Resilient Connections for SSH and TLS," USENIX Annual Technical 
Conference
* ports at L3 or L4 - Just because ports can be useful at L3, doesn't 
mean they should be moved to L3. A better answer is "Design for Tussle", 
ie on the wire it needs to be possible to have ports hidden or not, and 
everything works (for some definition of "works") whichever way you 
choose. {note 2}
* no ARP - looks useful to replace with an algo. The question then 
becomes how do you introduce new MAC layer addressing schemes in future 
- ARP is agnostic to the internal semantics of a L2 address, but an algo 
cannot be.
* stronger L4 checksums - useful, but needs to be considered as part of 
the bigger problem of L4 extensibility currently being addressed.
* IP-VRF - again the problem here is the extensibility architecture of 
existing IP. We can't keep changing to a completely new Internet 
Protocol every time we realise we missed an extension we should have 
thought of. Well it would be worth the change if the new Internet 
Protocol had a brilliant extensibility architecture...
* ...which raises a good question...

Where's your extensibility architecture? Should be the first design 
decision, not the last.


I'm trying to be helpful while being critical.

Cheers



Bob

{Note 1} If IPv6 had been proposed today, given how important everyone 
now knows incremental deployment is, it would have been rejected out of 
hand. Incremental deployment alongside v4 involved messy dual-stack, 
gateway and tunnelling additions, rather than incremental deployment 
intrinsic to the protocol design. And future protocol extensibility 
proved to be badly architected as well.

{Note 2} Ports can be added incrementally to L3, by 
agreeing/standardising the port fields as a shim betw layers, then 
altering protocols like IPsec ESP to move the SPI to the same location 
as the unencrypted ports would be found in. At the same time, the source 
IP port can be moved to this shim because it is really transport layer 
info, and the space where it was in the IP header can be used to double 
the bits for dest addresses (eliding the details on how to identify the 
different header format). See sourceless network architecture (SNA) from 
Jon Crowcroft and Marcelo Bagnulo Braun, and see Bryan Ford and 
Janardhan Iyengar: “Breaking Up the Transport Logjam”, HotNets-VII.


> Joe
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/