Subject: RE: [NSIS] NTLP draft

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 11 Nov 2003 16:21:17 -0000

hi john, georgios,

> > 1) Is it possible to separate the datagram mode (unreliable 
> mode) and
> > connection mode (reliable mode)
> > specifications in two separate protocol specifications (two RFCs)?
> 
> No.  We are making 1 NTLP RFC.

even technically, it would IMHO not be a good idea. big chunks of the
specification are common (e.g. message formats, routing state integrity
threats, v4/v6 transition, tunnel interactions...) and connection mode
requires datagram mode anyway.

however, probably the (near lack of) interaction between these two
modes could be better explained.

> 
> > 2) Is it possible to use (in some scenarios) the datagram mode
> > end to end (without supporting the connection mode)? Please note that
> > this mode selection procedure
> > might be different than the one that you have described in the draft.
> > Of course, if a NSIS node along the path will not support
> > this mode then an error message might be reported to the 
> > signaling sender.

functionally, if no NTLP node along the path decides to use connection
mode, then the datagram mode has been used end to end. i think we
have to make hard decisions about deciding to make functionality optional
which would then lead to more error conditions having to be signalled 
around.

to take a specific example: only supporting datagram mode implies 
imposing a maximum NSLP message size. if that maximum size is imposed
in the middle of the network, how is an NSLP at one edge (a) supposed to
find out and (b) get messages through it? it would mean that every
NSLP would have to be able to work in case connection mode was never
present, in which case there probably isn't much point in having it
(which may be what you are aiming at, of course!)

> >
> > 3) Why have you chosen in the datagram mode for UDP encapsulation
> > and not for "raw IP" encapsulation?

in broad functionality, i don't think there is much difference here
between the two. the differences are in details:
*) raw IP can allow interception on protocol number (or do we assume
RAO anyway)
*) UDP has a checksum which is nice (it's the same if you include
the RSVPv1 header, of course)
*) UDP will be easier to get through NSIS-unaware NATs (if we want to
do this)
*) some hosts can't easily do raw IP i/o (why RSVP allows UDP)
*) some hosts can't access the IP TTL *unless* you do raw i/o (if we
need to do this)
*) and so on.

i think we should aim to choose one option at this stage. on balance,
the arguments for UDP seem stronger at the moment. there is minimal
impact on the rest of the protocol high level design.

> > 
> > 4) It will be interesting if the Peer-Peer Tunelled Encapsulation
> > (Section 5.3.3) could be applied upstream and the 
> "End-to-End Tunnelled
> > Encapsulation" could be applied downstream. Is that possible?

that is possible. you don't have to use the same approach both directions
(the 'return path' could also be raw). the e2e version can only be used
downstream anyway. some people don't like either tunnel encapsulation
anyway - this is all very open (and views are sought).

> 
> Perhaps Robert or Henning could address these technical issues.

we aim to please!

r.

> John

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Nov 2003 12:07:57 -0500

> (which may be what you are aiming at, of course!)

There are other reasons beyond fragmentation to have connection mode, 
but I agree that MTU discovery in mixed mode is something we may need to 
consider or explicitly rule out. (It's basically the same as in IP - 
send until it hits boundary and get error message "message too large".)

I suspect that most NSLP messages have a natural size - you can't just 
cut the certificate in half if it exceeds the MTU.

However, I think this is essentially the wrong question. We should 
require *support* of connection mode, but allow messages to *request* 
datagram mode. This avoids the problem Robert mentions - every message 
gets through, but applications can choose datagram mode if that fits 
their need.

> impact on the rest of the protocol high level design.

In addition, firewalls may or may not be configurable for non-UDP/TCP 
protocols. Every firewalls seems to have the notion of port-based filtering.

> anyway - this is all very open (and views are sought).

We should definitely discuss this at the NSIS meeting. My current 
thinking is that encapsulation imposes complexity, makes implementation 
in certain circumstances rather tedious and it addresses somewhat 
ill-defined problems, so I'd love to hear arguments as to what can't be 
done in other ways.