Subject: RE: [NSIS] GIMPS connection mode and intermediaries

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Jan 2004 15:42:37 -0000

hi marcus,

> 
> I don't see the problem with the home networking, because 
> they do not have 
> that many connections running. So it really almost 
> end-to-end.

sure

> I see the 
> problem more in the number of c-mode endpoints on a NAT for 
> lets say a big 
> company network, where the NAT is handling a high number of 
> communications 
> with different partner -> different NATs. 

but will there be lots of different partners or just a few?
if there's just a few then that's just a few C mode connections.
(maybe a situation with 'many partners' would be remote
users with a VPN, but the VPN state will be huge compared to
C mode state.

> Or the GPRS 
> networks (where many 
> run NATs) and having a large number of flows.

this is the most problematic case that i see.

> 
> >
> > in any case, the underlying question is whether the state
> > involved in a C mode connection is much more, much less, or
> > about the same as required to manage the NAT processing for
> > that flow itself. do you think it could be more?
> >
> 
> I assume this depends on the used c-mode transport protocol, 
> so for example 
> TCP end-point state. For the NAT typically not the state but the fast 
> search in the state tables is the problem.

for an outgoing message it should be no harder (once the search
has been done) to look up the outgoing C mode connection 'handle'
(or whatever) directly.

for incoming messages, there are issues with simpleminded use
of select() or poll(), but these can be handled with more
sophisticated APIs (Henning's group have done experiments with
this). there is no answer to this question without more detailed
specification and some experiments.

> 
> 
> >> Plain GIMPS
> >> nodes would
> >> help with this problem.
> >
> > could you elaborate?
> >
> 
> If there are GIMPS-aware nodes in the network, the chances 
> are higher that 
> you can reuse the GIMPS transport protocol for parts of the 
> signaling path.

ok, as in Hannes' mail.

> [...]
> 
> > this is not my assumption. in a sane world
> > *) a GIMPS unaware NAT should not change the flow ID at all,
> > since it is just payload data.
> > [i am aware of NATs which look for things like IP addresses
> > in arbitrary payloads and attempt to rewrite them; I regard
> > being broken by such a NAT as a feature, not a bug ;-).]
> > but then the next GIMPS peer should detect the presence of
> > the NAT (see above) and then try to work out what to do about
> > it (as discussed a bit in Cedric's document).
> >
> 
> yes. Does GIMPS keep the previous nodes IP address in its payload?

that's not currently defined, but there would not be a problem
to do so e.g. in D mode. (it's not there currently because the
need only seems to arise in this NSIS-unaware NAT traversal case
which we have not really gone into yet).

> 
> 
> > *) a GIMPS aware NAT should change the flow ID in a way to
> > be defined by the GIMPS spec, for which at the moment I
> > see several possibilities:
> >  - use existing bindings if they apply to that flow
> >  - if there is no applicable existing binding, create one, or
> 
> This one of these 2 actions are performed in the NAT/FW NSLP 
> spec 00 (no 
> problem to move them to NTLP

this is where some alignment is needed. this function is about
NATFW management but the need for it seems to be common to all
NSLPs.

> 
> >  - if there is no applicable existing binding, return an error
> >    to the peer (this would be one of a large class of "I couldn't
> >    handle that flow ID errors")
> >
> >>
> >> And it does matter whether the NAT is GIMPS aware or not.
> >
> > it matters to the GIMPS D mode implementation. it should not
> > matter to the overall function split between C and D mode,
> > and it should not matter to NSLPs.
> >
> 
> Sure, I was not referring to any d-mode at all in that mail.
> D-mode might be a prblem anyway when you run an "intelligent" NAT.
> 
> Marcus
> 

r.

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 29 Jan 2004 18:32:28 +0100

> but will there be lots of different partners or just a few?

I assume many different ones.

> users with a VPN, but the VPN state will be huge compared to

I was more thinking about with how many partners is bigger company like 
yours having telefon conversation outside the company.

Marcus