Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for commentson proposals.

From: "Kaushik Biswas (kbiswas)" <[email-masked]>
Date: Sun, 28 May 2006 20:28:16 -0700 (PDT)

Increasing the delay in sending icmp error may give a chance to the
endhost whose CPU is overloaded a chance to process this and lead to
more predictable behavior compared one with a shorter window, but then
we also say the following in option 4:

 "If the NAT does not have resources to delay the ICMP, it MUST silently
drop the
  inbound SYN" 

Doing such, will not be a very deterministic behavior for NATs.
Sometimes NATs will generate the ICMP errors and other times it will
silently drop the inbound SYNs. 

I know we haven't yet concluded on which option to take, but if the list
agrees on Option 4, my suggestion would be to not put the above line.

Thanks,
Kaushik

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Philip Matthews
> Sent: Sunday, May 28, 2006 6:02 PM
> To: Joe Touch; Saikat Guha
> Cc: tcpm-chairs@xxxxxxxxxxxxxx; behave-chairs@xxxxxxxxxxxxxx; 
> Behave WG; Lars Eggert
> Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: 
> Request for commentson proposals.
> 
> Just one more point about option 4:
> 
> My concern (expressed below) about option 4 revolves around 
> the short time window (3 seconds) that was suggested. If this 
> window was instead, say, 60 seconds, or perhaps even 30 
> seconds, I would not have this concern.
> 
> I don't know if there is any way to make the window larger 
> without losing all the debug advantage of sending the ICMP 
> message in the first place, but if there was, this might be a 
> way forward.
> 
> - Philip
> 
> 
> 
> On 26-May-06, at 12:02 , Joe Touch wrote:
> 
> >
> >
> > Philip Matthews wrote:
> >> I feel it is important to make TCP Simultaneous-Open work.
> >>
> >> Regarding option 4:
> >> I feel that coordinating peers so they do things at the 
> same time can 
> >> be difficult.
> >> If peers A and B are trying to set up a connection between 
> them, but 
> >> peer B gets busy doing something else for a few seconds and misses 
> >> the 3 second window, then the whole connection attempt 
> fails. In our 
> >> product (a peer-to- peer telephony system), we see 
> situations where 
> >> the CPU on one hard-phone can get very overloaded for a 
> few seconds. 
> >> I could easily see that this option would lead to situations where 
> >> the connection would be established most of the time, but would 
> >> randomly fail from time-to-time because the 3 second window was 
> >> missed.
> >
> > It'd be useful if option 1 is chosen to note that this is 
> "intended to 
> > relax TCP requirements to accommodate NATs". For a similar 
> relaxation, 
> > see the discussion of ICMP processing in RFC4301. Like for 
> IPsec, this 
> > MUST be configurable if chosen.
> >
> > Note, though, that 4301 falls short of defaulting the 
> configuration to 
> > 'drop all'.
> >
> > Joe
> >
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Saikat Guha <[email-masked]>
Date: Mon, 29 May 2006 10:07:32 -0700 (PDT)

(CC list trimmed)

> silently drop the inbound SYNs. 

While the choice of option is still open, I don't think this construes
as non-deterministic behavior any more than that inherent in a router
that needs to rate-limit ICMP packets.

In any case, while the 'indication of the error' is non-deterministic
under heavy load, the behavior of allowing S-O / P2P TCP connectivity is
very deterministic from the app developers perspective.

-- 
Saikat
Attachment:
signature.asc