RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

Hi Eric, 

> Bound, Jim wrote:
> 
> >>Nobody has proposed changing the IP addresses that are seen 
> >>on the wire. 
> >>All we are changing is to add a dynamic mapping between what IP 
> >>addresses the transport and above sees (the ULIDs) and the IP 
> >>addresses 
> >>the routing system sees.
> > 
> > 
> > That is not crystal clear to me in the spec above at all.
> 
> OK. If you have specific things that are unclear I can make a pass at 
> clarifying those in the next rev.

OK I will as I can.  I think the key issue is to clearly state IP
addresses are on the wire not ULIDs. Then for applications what do ULID
semantically look like exactly, or to current management interfaces on a
node etc.

> 
> 
> > Something different.  Map an TCP request to an SCTP request 
> as if the
> > transport selected was SCTP.
> 
> But that has quite more limited applicability than a shim.

That is not my point but I am not sure I agree.  My point is SCTP solves
the problem of passing ULIDs with an extension, and in addition supports
inherent failover of IP addresses to a new interface within its
architecture.  If passing ULIDs is in fact a good idea.

> First of all, the peer need to do the same (which is also the 
> case for 
> the shim) thus you need a very performant approach to 
> failback to using 
> TCP when the peer doesn't support this.

Why does this matter? If only addresses are passed on the wire.  ULIDs
should only be beneficial operationally to a node local scope not
between other nodes or peers is my view, other than to find an address.

> It is hard for me to see an 
> approach using SCTP that can be as efficient as the shim, because the 
> shim defers its work thus there is no extra work (state or 
> packets) for 
> short-lived connections.

As I said most of what is needed to failover to a new interface and
address is in fact part of SCTP. Much of the shim is to operate with
locators and that I am not convinced is warranted overhead to solve the
multihoming problem at all.

> But the SCTP providing the TCP socket API also has the issue that the 
> SCTP protocol can't provide the identical service as TCP, 
> with all the 
> details of TCP urgent data being the prime example. Even if almost no 
> applications use that aspect of TCP, it means that you can't 
> claim 100% 
> compatibility for the SCTP approach, whereas the shim can 
> make such a claim.

We can get close enough until this is implemented more efficiently and
then transition to SCTP.

Also I am less concerned about locators and identification than the more
important issue of failover to new ISP and interface which I think is
the first order of business.  This will reduce sending to same address
to same ISP etc or all the issues of not having specific address and
interface for different ISP and solve the real problem which is having
ISPs have to hold all perhost routes for another ISP.

> Finally, SCTP doesn't help for UDP communication.

That is true but UDP won't work that well for failover of address and
interface either with the shim approach.  Regarding passing ULID that
can be lightweight UDP protocol we define though, if that is important.

> 
> So while SCTP has many useful features, I don't see it as the 
> ideal fit 
> for something that we want to shim in under existing applications and 
> have everything work without application changes.

I think it depends which problem is to be solved.  If just failover to
new interface and potentially new address I think SCTP solves the
reliable transport problem better.  

If it is just a matter of ULID use then maybe not.

I also fail to see at all how ULID solves the issue of failover to new
interface and adddress except as round robin essentially in the kernel
and this could be done in user space if we had a ULID format and
architecture then shim would only be optional regarding implementation
of the method.

> Thus I'm interesting in figuring out how SCTP and the shim 
> can work well 
> together for the many cases where SCTP is the right transport 
> protocol 
> to use.

Well first question is do two nodes need to pass ULIDs to each other?   

> 
> 
> >>I'd like to understand why you think a DST option in every 
> packet is 
> >>necessary. Such a thing would be complete untrusted.
> > 
> > 
> > Yes the trust would be a problem.  Could be reference to 
> look for ULID new
> > extension header then which could be encrypted with IPsec 
> then.  The reason
> > to pass the ULIDs is to save processing on each node for 
> mapping to them at
> > the transport and above.  This shim now will require a 
> search for ULID on
> > every packet. Providing the ULID in the packet avoids that 
> on every system?
> 
> If you want intermediaries (middleboxes) to use the ULID, 
> then carrying 
> it encrypted doesn't help, since they either don't have the 
> key (hence 
> can't decrypt to read the ULID), or they have the key and can 
> spoof the 
> ULID and thereby fool the next middle box.

I find such a concept of middle boxes doing this quite evil and breaks
end-to-end so I don't care about middle boxes and in industry state
strongly don't use them except as service when required to be called by
an app. So your telling this to the wrong architect/engineer :--)

> 
> For the endpoint, the processing to lookup the context state and find 
> the ULID is quite small, and in the common case of the ULID being the 
> same as the locator (which is the case before any failure has 
> happened)
> close to zero.
> For example, if the shim and no failure happens, the packets would be 
> the same as today (IPv6 followed by TCP, for instance) and the shim 
> would be close to a no-op. (I say "close to", because the shim might 
> want to count the number of packets so that it can determine whether 
> this is a long-lived communication i.e. whether it is worth-while to 
> establish multi6 state so that the communication can be 
> rehomed should a 
> failure occur).
> After a failure has occurred and the communication has been 
> rehomed to 
> use a different address pair, then the receiver needs to lookup the 
> context state and modify the packet before passing it to TCP etc.
> That does entail a lookup operation, but depending on details in the 
> protocol design it might be possible to have this be just an array 
> lookup based on an index in the packet (that's part of what 
> the receive 
> side demultiplexing issue is about in the shim draft).

The address pair reference above is what SCTP does so well and can do
better than TCP.

So what is the added value of a ULID or concept of locator?  I simply
think this is unecessary.

> 
> >>Thus it would be 
> >>better if middleboxes that want to do verification either
> >>  - get explicitly signaled from the endpoints so that they 
> >>have the list
> >>    of IP addresses
> >>  - observe the sim6 signaling protocol and do the same 
> >>verification as
> >>    the endpoints do as a way to discover the list of IP addresses
> >>Both of those can be reasonably secure.
> > 
> > 
> > Yes that is possible but was trying to avoid this and keep 
> e2e only and as
> > needed also if they change that can be accomodated too.
> 
> Agreed.
> 
> I was confused and thought you wanted the DST option for 
> middleboxes and 
> not for the endpoints

Yes for the end points.

I guess from architecture view I do not believe we need locators to
solve the multihome problem at all too..
> 
>     Erik

Thanks
/jim