Subject: RE: [Simple] Objects to NATs kill TCP connection

From: [email-masked]
Date: Wed, 19 Nov 2003 13:13:28 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul Kyzivat
> Sent: 18.November.2003 21:13
> To: Ben Campbell
> Cc: Jonathan Rosenberg; Cullen Jennings; [email-masked]
> Subject: Re: [Simple] Objects to NATs kill TCP connection
> 
> 
> 
> 
> Ben Campbell wrote:
> > Can we reasonably assume that all connection failures are 
> due to NATs? 
> > What happens if endpoints do this when the failure is caused by 
> > something else?
> 
> Good point. That could be ugly - I don't see any easy way to 
> know when 
> the connection fails because of NAT. Lacking that it seems 
> infeasible to 
> test for the NAT timeout interval.
> 
> Are there any standard practices in this regard? In other words, is 
> there a keepalive time we could use that would be sufficient 
> most of the 
> time and still not be too impractical to keep up?

To be safe, you need a keepalive message every 30 seconds. You can always send empty TCP packets.

Shouldn't this anyway be a relay problem? maybe a BIND is sent to the relay every x seconds.

Regards,
Hisham

> 
> 	Paul
> 
> > Paul Kyzivat wrote:
> > 
> >> Letting msrp keepalives act as NAT binding keepalives seems 
> >> attractive. Perhaps the NAT keepalive time needs to be determined 
> >> adaptively. If the connection is found to be down, a 
> reinvite could 
> >> reconstruct it, and a new keepalive timer could be set, 
> shorter than 
> >> before.
> >>
> >> But this would require negotiating the keepalive time.
> >>
> >>     Paul
> >>
> >> Jonathan Rosenberg wrote:
> >>
> >>> The trick, as always, is knowing what the nat keepalive 
> is. There is 
> >>> no easy way to know.
> >>>
> >>> -Jonathan R.
> >>>
> >>> Ben Campbell wrote:
> >>>
> >>>> When we were having the recent discussion on the 
> inactivity timeout 
> >>>> for MS(R)P, I don't think we thought much about the fact 
> that MSRP 
> >>>> keepalive messages may also act as NAT binding keepalives.
> >>>>
> >>>>
> >>>>
> >>>> Jonathan Rosenberg wrote:
> >>>>
> >>>>> Short timeouts are broken, sure, but the fact that NATs have 
> >>>>> timeouts on bindings is a common behavior. As a result, 
> if there is 
> >>>>> no traffic on the TCP connection before the timeout occurs, the 
> >>>>> binding is lost, and any data sent on that connection will fail.
> >>>>>
> >>>>> Therefore, I think we can expect to see cases where the 
> connections 
> >>>>> close due to NAT.
> >>>>>
> >>>>> Now, the question is, do we think we would see periods of 
> >>>>> inactivity on the messaging will exceed a typical nat 
> timeout? I 
> >>>>> think they may. I personally tend to leave IM sessions open 
> >>>>> continuously all day..
> >>>>>
> >>>>> -Jonathan R.
> >>>>>
> >>>>> Ben Campbell wrote:
> >>>>>
> >>>>>> I have personally encountered this behavior in the 
> wild. I agree, 
> >>>>>> however, that it was broken, and probably not a normal 
> use case. 
> >>>>>> And as far as I know, it pretty much killed anything 
> other than 
> >>>>>> hit-and-run HTTP connections.
> >>>>>>
> >>>>>> Paul Kyzivat wrote:
> >>>>>>
> >>>>>>> Cullen,
> >>>>>>>
> >>>>>>> I don't have any data of my own on this subject, but 
> I hope you 
> >>>>>>> are right.
> >>>>>>>
> >>>>>>> It would be a lot simpler if we can continue to 
> assume that the 
> >>>>>>> way you reestablish an MSRP session is via a reINVITE. The 
> >>>>>>> adequacy of that was under question if NATs regularly 
> blow away 
> >>>>>>> connections.
> >>>>>>>
> >>>>>>>     Paul
> >>>>>>>
> >>>>>>> Cullen Jennings wrote:
> >>>>>>>
> >>>>>>>> There was some assertion in the WG meeting that NATs 
> arbitrarily 
> >>>>>>>> kill TCP
> >>>>>>>> connection and the connection needs to be set up 
> again. I'm sure 
> >>>>>>>> this has
> >>>>>>>> happened with broken NATS but I do not feel it is 
> widespread and 
> >>>>>>>> don't think
> >>>>>>>> we should specifically design for it. I do think we should 
> >>>>>>>> design for
> >>>>>>>> graceful failure or recover when things in the 
> network fail but 
> >>>>>>>> I don't
> >>>>>>>> think there is a common case of TCP failing that 
> involves NATs. 
> >>>>>>>> If there
> >>>>>>>> were, many things that do not automatically set up a new TCP 
> >>>>>>>> connection,
> >>>>>>>> like ssh for example, would be nearly unusable through these 
> >>>>>>>> broken NATs.
> >>>>>>>>
> >>>>>>>> Cullen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Simple mailing list
> >>>>>>>> [email-masked]
> >>>>>>>> https://www1.ietf.org/mailman/listinfo/simple
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Simple mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://www1.ietf.org/mailman/listinfo/simple
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Simple mailing list
> >>>>>> [email-masked]
> >>>>>> https://www1.ietf.org/mailman/listinfo/simple
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Nov 2003 08:23:00 -0600

> Shouldn't this anyway be a relay problem? maybe a BIND is sent to the relay every x seconds.

It can occur without any relays. For example, what if one (the active) 
endpoint is natted and the other is not? This scenario works with no relays.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Nov 2003 08:23:00 -0600