Re: Comments on draft-ietf-multi6-v4-multihoming-02

[Joe Touch <touch@isi.edu>]

john.loughney@nokia.com wrote:
...
> > How is an application ever going to do anything useful in this area, 
> > even assuming applications that are smart enough (which they won't be)? 
> > Their interaction with the network is obscured by a transport layer 
> > which generally hides any unreachability, and the multihoming layer 
> > which hides address changes. It's like driving a car from inside the 
> > trunk.
>
>
> At the same time, how does the multi6 layer understand what kind of 
> connectivity the application needs?

It can't unless it knows whether its TCP or UDP, which (strictly) it 
can't know either (e.g., IPsec-encrypted).

> With wireless links, its really
> easy to get intermittent connectivity. How do we classify when the
> connectivity is too poor to be useful - the application should be able
> to determine this and ask for using a different address pair.
>
> John

If the connectivity doesn't allow a TCP connection to be used with 
little or no delay whenever the app deems it necessary, there's a problem.

----

Has anyone considered keeping the connection 'active' (i.e., keepalives) 
for sessions for around 1-2 typical RTTs of idle? That would catch TCP 
idles that still allow TCP bursts; anything longer than that and TCP is 
supposed to 'restart' its congestion control anyway.

That might be a happy medium to the 'all or none' keepalive. I.e.,
"keepalive for 1-2 RTTs of idle".

Joe

Attachment: signature.asc
Description: OpenPGP digital signature