[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: TCP transport draft

Comments below. 

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On
Behalf Of Alan DeKok
Sent: Wednesday, November 19, 2008 10:33 AM
To: 'radext mailing list'
Subject: TCP transport draft

  The WG meeting yesterday raised a number of potential issues with the
draft.

  1) The document doesn't discuss UDP -> TCP and TCP -> UDP issues when
proxying packets.  This needs to be updated.  

[BA] There are several situations in which the law of "conservation of
packets"
could be violated on an end-to-end basis (e.g. where more packets could
enter
the system than could leave it on a short-term basis): 

a. Where TCP is used between proxies, it is possible that the bandwidth
consumed by incoming UDP packets destined to a given realm could exceed the
sending 
rate of a single TCP connection to that realm, based on the window size/RTT
estimate. 

b.  It is possible for the incoming rate of TCP packets destined to a given
realm to exceed the UDP throughput achievable using the transport guidelines
established
in RFC 5080.  This could happen, for example, where the TCP window between
proxies
has opened, but packet loss is being experienced on the UDP leg, so that the
effective congestion window on the UDP side is 1. 

Intrinsically, proxy systems operate with multiple control loops instead of
one end-to-end
loop, and so are less stable.  This is true even for TCP-TCP proxies.  As
discussed in 
RFC 3539, the only way to achieve stability equivalent to a single TCP
connection is to 
mimic the end-to-end behavior of a single TCP connection.  This typically 
is not achievable with an application-layer RADIUS implementation regardless
of transport. 


There are also head-of-line blocking issues when there are sudden spikes of
traffic.

[BA] HoL blocking can occur whenever there is packet loss on a TCP
connection.
This need not necessarily correspond to sudden RADSEC traffic spikes, but
could
be due to background traffic. 

  2) The document needs more review from the transport area for TCP issues.

[BA] I will send a message to the tsv-dir requesting assignment of a
Transport
Advisor. 

  3) TCP && RadSec.

	Q: Does the WG want to *forbid* "raw" TCP transport?

  i.e. TCP MUST be used with RadSec.  TCP MUST NOT be used to transport
bare RADIUS.

[BA] My suggestion would be to coalesce sections 1.1 and 1.2 into
an Applicability section in which the intent of the document
(to address transport relating to RADSEC) could be described, along with the
RECOMMENDED and NOT RECOMMENDED uses. I'm not sure that a MUST NOT is
necessarily
required; perhaps a NOT RECOMMENDED might be sufficient, along with a
reference
to the caveats described in Section 2.4 of RFC 2865. 

Another way to make it clear that "raw TCP" is not recommended for prime
time
would be to classify the document as Experimental.  If the document is
largely 
focused on use with RADSEC, this would be consistent with RADSEC's
Experimental
status.

  4) Use of Status-Server as the RFC3539 watchdog timer packet.  The
issues surrounding Status-Server means that 1 RADIUS ID will have to be
dedicated to Status-Server.  This means that there can only be 255
packets "in flight" on one TCP connection.

	Q: Does the WG want to stay with Status-Server, or define a new
	   packet code?

[BA] My advice would be to describe the Status-Server ID issues in
that document, and talk about some of the Transport implications in
this one.  Once we've understood the implications and alternatives,
we can explore whether a new packet code is warranted.  However, the
current charter of the Status-Server document is to describe the
existing protocol rather than attempting to fix/radically improve it. 

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>