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

[email protected] 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBk3OIE5f5cImnZrsRAiXlAKDziqUO3tsPd2Iy28eRBfCuZvkwCQCeLPtP
hcJQsilU0lLygiWXRoFoCho=
=L1oV
-----END PGP SIGNATURE-----