Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt

From: "Christian Dickmann" <[email-masked]>
Date: Fri, 20 Apr 2007 11:03:40 +0200

Hi Jukka.

> The point was that the spec could say it clearly, how one uses
> "Forwards-UDP", e.g., do you send the Confirm to the GIST port, or do
> you
> get an alternative port number in the Response?

No, the point is: The spec does NOT define "Forwards-UDP" and does not
intend to do so. If you want insecure UDP, just use D-Mode. If you want
secure UDP, then this is not supported at the moment. And as Lars and
John pointed out in their mails, we should not add new features (which a
"Forwards-UDP" would be) without any really good reason. If you really
need this mode, you can write an additional document that specifies
"Forwards-UDP" (similar to our doc that specifies "Forwards-SCTP").

Christian

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 20 Apr 2007 10:37:41 +0100

hi, 

> -----Original Message-----
> From: Christian Dickmann [mailto:[email-masked]] 
> Sent: 20 April 2007 10:04
> To: Jukka MJ Manner
> Cc: nsis; Hancock, Robert
> Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt
> 
> Hi Jukka.
> 
> > you get an alternative port number in the Response?
> 
> No, the point is: The spec does NOT define "Forwards-UDP" and 
> does not intend to do so. If you want insecure UDP, just use 
> D-Mode. If you want secure UDP, then this is not supported at 
> the moment. And as Lars and John pointed out in their mails, 
> we should not add new features (which a "Forwards-UDP" would 
> be) without any really good reason. If you really need this 
> mode, you can write an additional document that specifies 

this is precisely what one would have to do. we haven't done it
yet but there is nothing in the protocol architecture that
prevents it being done if there is a need for it.

there is something in the 'acceptability rules for extensions'
that would prevent a simple definition of a Forwards-UDP option.
That is, we require congestion control for signalling traffic
unless one of two conditions applies:
i) it is logically impossible (i.e. for Query messages and
Responses), in which case the rate limit applies
ii) you can engineer capacity for signalling traffic and rate
limit to that.

the way this restriction is phrased in the spec is to say that
you have to use C-mode unless conditions (i) or (ii) applies.
but defining a Forwards-UDP with no other constraints would
invalidate this. What I think would be rational would be to 
define Forwards-UDP with the same applicability restrictions
as D-mode (i.e. MUST NOT offer or accept unless capacity can
be engineered for it).

note that as a special case of the above, if the peer is one
hop away and you are on a link with explicit capacity
allocations (including the case of a point-to-point link)
then the 'engineered capacity' clause automatically applies
(the node sending the signalling traffic decides inside its
own networking stack how much of the link to use for signalling).
This probably covers a number of the wireless scenarios.

If you want a license to send un-congestion-controlled 
signalling traffic in general topologies, take it up with the
transport ADs & good luck :-)  Although there are examples of
RFCs which imply the sending of uncontrolled bursts of data
over UDP (the DTLS spec itself, for example), we aren't allowed
to get away with that in this working group.

r.