Subject: RE: Comments on draft-ietf-multi6-v4-multihoming-02

From: <[email-masked]>
Date: Wed, 10 Nov 2004 17:16:47 +0200

Hi Iljitsch,

> I'm sure there are, but I'm just as sure there are also people like me 
> who prefer the session to remain up so there is no need to reconnect 
> after waking up. FYI: SSH disconnects after several hours by default, I 
> think because of an automatic 2-hourly TCP keepalive. I managed to make 
> it such that sessions would remain up overnight but that doesn't work 
> anymore since one upgrade or another.

Right, so assuming a default behavior here is probably wrong.
 
> > I agree that supressing keep alives when traffic is flowing is 
> > reasonable.
> > Supressing when no traffic is flowing is debatable.  If you are doing
> > site multihoming and want to make sure you maintain site connectivity,
> > you might want to have keep-alives.
> 
> No, this is something that has the potential to be harmful. If 
> transports or applications feel they need to keep sessions alive 
> explicitly, they are free to do so and multihoming mechanisms will make 
> sure that rehoming happens if such a keepalive doesn't make it. But if 
> multihoming does the keeping alive, there is no way for transports or 
> apps to be network-quiet if they want to be.

So, are you suggesting that if we want to maintain any multihoming bindings,
we should rely on application layer keep alives?  I guess that is another
possibility, especially if we consider 'testing' connections at session
startup, that then might be sufficient.
 
> > I'd propose that sending keep-alives might be a tunable setting, and 
> > the timing of sending keep-alives could be set according to policy 
> > (host or site).
> 
> Disagree vehemently. Polling is bad, interrupts are good.

From your earlier mail, it wasn't clear, let me just quote you:

> The non-obvious solution is to suppress keepalives when it's clear that 
> they aren't needed. This can happen in two cases:
> 
> 1. When there is no traffic in either direction
> 2. When there is traffic in both directions
> 
> Only when there is traffic in only one direction there MAY be a failure 
> condition, so keepalives are in order to make sure. This should work 
> very well except that failures may now only be detected by one end. For 
> instance, when A and B communicate and there is only reachability from 
> A to B but not the other way around, A won't detect the failure if B is 
> sending data, because A is both receiving B's data and sending out 
> ACKs. However, B will see data going out but nothing coming back so B 
> notices the potential failure and can trigger reachability testing.

So what I meant more was that if we use keep-alives at the multi6
layer, then perhaps this could be something that the upper layer
could set the keep-alive behavior.  However, I still don't know if
you are suggesting that we use keep-alives at the multi6 layer
(in some circumstances) or if you would kick this up to the application
layer.

John

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Nov 2004 17:26:39 +0100

> Hi Iljitsch,
...
> (in some circumstances) or if you would kick this up to the application

IMHO: In a modular multi6 design, this shouldn't be prescribed.
The connectivity detection component might use keep-alives on Tuesdays,
SNMP traps on Wednesdays, and hints from the ULP the rest of the week.
This really should not become an architectural choice.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Nov 2004 18:28:08 +0100

On 10-nov-04, at 16:16, <[email-masked]> wrote:

> we should rely on application layer keep alives?

Certainly not. What I'm saying is that if applications want to be sure 
a session remains available, they should send keepalives. Then, if the 
session goes away, the app gets to hear about it without much delay.

As far as multihoming goes, we have no business repairing connectivity 
that isn't used. Not only does this use up unnecessary bandwidth, it 
also means unnecessary work as the failures we try to repair may have 
gone away on their own when the communication resumes. There is really 
no upside to being overzealous here.

> could set the keep-alive behavior.

I could just go on disagreeing, but let me ask you this: assuming a 
decent multihoming solution, under which circumstances would upper 
layers want to do something like that, trying to achieve which 
benefits?

> However, I still don't know if you are suggesting that we use 
> keep-alives at the multi6 layer (in some circumstances) or if you 
> would kick this up to the application layer.

The multihoming layer needs find at least one working address pair (if 
it exists) from the set of all possible address pairs. If we assume 
bidirectional connectivity this isn't all that difficult: send a 
ping-like packet and see if something comes back. But we need to be 
able to use two unidirectional paths rather than one bidirectional one 
in a world where it's possible that routing and ingress filtering get 
in each other's way. Unidirectional reachability testing is a lot 
harder as we need the results of the reachability testing in one 
direction in order to send back the results of reachability testing in 
the other direction.

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.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 11 Nov 2004 05:03:59 +1100

>This really should not become an architectural choice.

precisely - and I believe that this was noted in the architecture draft

   Geoff

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Nov 2004 21:11:26 +0100

> precisely - and I believe that this was noted in the architecture draft

I think it makes more sense to accept hints from elsewhere, but do a 
quick additional check inside the multihoming protocol too. This way, 
SNMP traps (?) and ULPs don't have to bother implementing all the nitty 
gritty security details but they can just hand off their information 
and be done with it.

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Nov 2004 17:50:41 -0800

Iljitsch van Beijnum wrote:
> Certainly not. What I'm saying is that if applications want to be sure a 
> session remains available, they should send keepalives. Then, if the 

That's not true for TCP connections today, or anything below it - the 
session remains available until it is closed, even if unused. Doesn't 
this then change the semantics of 'application silence'?

I don't want unused sessions to consume bandwidth switching around, but 
they shouldn't go away per se.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Nov 2004 10:05:41 +0100

>> Certainly not. What I'm saying is that if applications want to be 
>> sure a session remains available, they should send keepalives. Then, 
>> if the session goes away, the app gets to hear about it without much 
>> delay.

> I don't want unused sessions to consume bandwidth switching around, 
> but they shouldn't go away per se.

I completely agree. That's why the multihoming mechanism shouldn't do 
keepalives on idle sessions. If the opposite behavior is desired, 
applications or transports should do keepalives.

>> I think triggering slow start is pretty much all you can do to slow 
>> down TCP

> You mean slow-start restart, right?

> I.e., you want to behave like you lost enough information that you 
> start from the ground-state with congestion control. It should act 
> like restarting after idle, more than just 'going into slow-start'.

Yes. It's been a while since I studied RFC 2001.  :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2004 13:24:13 +0100

> applications or transports should do keepalives.

I think it's interesting to speculate why keepalives seem to be widely
used, at least by tunneling solutions, today. Perhaps it is in practice
to keep NAT state alive - that is certainly the case with at least one
of the corporate remote access "VPN" solutions I use (the one that
runs IP over TLS and punches through even the most lame NATs). If that
is true, then the need for keepalives will be much less in multi6
and we could recommend the optimistic approach (assume connectivity
is still there until something tells you it isn't).

But that assumes we have a good solution for deleting multi6 state
when it is no longer needed.

     Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Nov 2004 06:07:55 -0800

> applications or transports should do keepalives.

But that argues that applications are responsible for the use of 
multi6-based transport connections. Applications should (MUST?) be able 
to be ignorant of such use (otherwise all apps need revision).

Brian's note about NATs is useful in this context; this is another 
reason that complicates their use, not a reason to argue that 
applications are thus responsible. Apps. rely on transports to maintain 
state. TCP already supports connections that are silently (to the 
transport layer) maintained; anything short of that here is going to be 
a problem, IMO.

Joe