Re: shim-aware transports

[Brian E Carpenter <brc@zurich.ibm.com>]

Iljitsch,

Iljitsch van Beijnum wrote:
> As a result of the discussion in the shim6 session in Paris it  occurred 
> to me that we've been focussing too much on making the shim  work with 
> unmodified IP and unmodified upper layers.
>
> This is of course extremely important, no question about that.

And needs to get shipped first, to resolve the ISPs'concerns about
IPv6 deployability.

> But if we're successful, it won't be long before existing transports  
> are modified or even new ones are created that know about the shim  and 
> may be able to make the shim work better. Other transports may  already 
> be doing work that the shim must also be able to do, like SCTP.
>
> I think this implies that our efforts basically consists of two  parts, 
> or should consist of two parts:
>
> 1. The basic shim functionality that for some reason or another  should 
> NOT be implemented in transports. For instance: reachability  detection, 
> state management and security. Having each transport do  these on its 
> own is a waste of resources and my lead to suboptimal  results if one or 
> more transports doesn't get it right.
>
> 2. Multi-address handling and transport-specific (potential) failure  
> detection. For instance, TCP has a good idea about when its sessions  
> aren't progressing (hence the talk about hints), SCTP can also handle  
> multiple addresses.

Yes, but you need 2a: the stateful handling of all this in the shim
layer to support the unmodified ULPs. And that is more urgent than 2.

> (note the difference between failure and reachability detection.)
>
> The idea would be that the basic shim sublayer provides a set of  
> required building blocks. I'll call the other sublayer the "adaption  
> layer" because it adapts existing transport behavior to the  
> requirements of the shim. Transports or even applications that know  how 
> to work with the shim themselves may bypass the entire adaption  layer, 
> or specific parts.

Sure, that's 2a.

> This would allow for the following succession in TCP/shim developments:
>
> - Initially, TCP would be unmodified, so the shim would use the  
> adaption layer to do address magic whenever the basic shim sublayer  
> determines reachability has changed.
>
> - Next step: TCP is modified slightly to provide reachability hints  to 
> the shim layer. The basic shim sublayer can optimize some of its  
> failure/reachability detection mechanism based on this.
>
> - Finally: TCP becomes aware of multiple addresses, and starts  keeping 
> per-address pair RTT statistics. TCP moves to another address  pair 
> either when the shim tells it to (because the shim detected a  problem) 
> or when it determines another pair is "better" based on its  own 
> statistics.

Don't forget that SCTP already contains some of this logic, and maybe
DCCP needs to as well.

Thanks for articulating this. It's been in my mind for a while but I
never managed to say it clearly. It's the correct response to those who
say the problem should be solved in layer 4 - actually it has to be solved
by cooperation between layers 3 and 4.

BTW it implies a two-way API between the shim and the ULP, in which the
necessary events are transmitted up or down.

     Brian