headers
Qiaobing Xie | 4 Dec 2002 21:38

Re: Multihoming with NAT

Hi, La Monte,

(cc'ing this to tvswg list... this is more than implementation I think)

...
> I'm not convinced that we have an immediate and burning need for work
> on multi-homed SCTP support behind multiple NAT boxen.  I'll not go so
> far as to say that work on "Inter-NAT SCTP Coordination Protocol"
> would be a BAD idea.  I just think that the SCTP community has more
> important work right now.

I don't think I can speak for the SCTP users, though :-) For those companies who
are currently looking at deploying SCTP for their services (I hope there are) and
their infrastructure already contains multiple NAT/middle boxes, this becomes an
"immediate and burning" need.

Personally, I feel the same as you do, that I don't have any bandwidth to work on
the problem now. But I wouldn't discourage others from work on it. There are
plentiful of works going on, across multiple WGs, to address UDP and TCP middle
box transverse issues, such as stun, but very little is happening for SCTP, which
is not good for SCTP's future. I wish someone could have cycles to follow those
works and ensure SCTP is adequately considered in their solutions.

Technically, SCTP's multi-homing nature does make it more a challenge than UDP and
TCP for middle box transverse, but I don't think it is un-solvable. The hostname
parameter in SCTP just gives SCTP one more weapon/tool/flexibility than TCP or UDP
to deal with the problem. And in my mind I don't automatically map the SCTP
hostname parameter to a DNS-qualified hostname - since it is defined as a TLV, I'd
prefer to view the parameter as a versatile, generic alternative addressing id.
It's a hook, not a solution by itself, that could be mapped to things such as a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Williams, Jim | 4 Dec 2002 23:01
Favicon

question on PDU alignment

It has been proposed that is some cases
(i.e. RDDP) that PDUs be aligned with TCP segments.

I have a question as to how this interacts with
slow start and delayed ack.  I may be wrong
on some of my assumptions and welcome correction.

Certain TCP implementations may withhold sending
ACK until either 2*MSS data has been received, or
the delayed ack timer (up to 500ms) has expired.

At the beginning of slow start, the congestion
window will be 2*MSS which is normally sufficient
to trigger and ACK.  However with the addition
of alignment requirement, the sender may have
many PDUs to send which are (for instance) one
byte smaller than MSS.  So the sender must
either send two PDUs and wait for the delayed
ack timer on the remote end to expire before
sending any more data, or must send three
PDUs and violate the congestion window.

The right answer is probably to increase the 
initial size of the congestion window at the
beginning of slow start.

I may be all wet here, so I appreciate either
confirmation or correction.

Thanks, Jim
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Lahey | 5 Dec 2002 00:45

Re: question on PDU alignment

On Wed, 4 Dec 2002 17:01:42 -0500 
"Williams, Jim" <Jim.Williams <at> Emulex.com> wrote:

> It has been proposed that is some cases
> (i.e. RDDP) that PDUs be aligned with TCP segments.
> 
> I have a question as to how this interacts with
> slow start and delayed ack.  I may be wrong
> on some of my assumptions and welcome correction.
> 
> Certain TCP implementations may withhold sending
> ACK until either 2*MSS data has been received, or
> the delayed ack timer (up to 500ms) has expired.

My impression is that at least several modern TCP implementations have
moved away from sending ACKs based on the receiver's notion of the
MSS.  This can break badly in the face of path MTU discovery, when,
for instance, the receiver expects 1460-byte segments, but the path
permits only 536-byte segments.  Clearly, waiting for 2920 bytes before
ACKing would be problematic in this case.

IIRC, NetBSD sends an ACK for every two data packets, regardless of size.
I've heard (but can't confirm)  that Linux does all sorts of interesting 
stuff, including sending more frequent ACKs during what it guesses is
slow-start, to speed up the process.

In short, I would guess that this shouldn't be a concern.  I eagerly
anticipate my come-uppance.  :-)

Kevin
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 5 Dec 2002 01:45
Favicon

Re: Re: Multihoming with NAT

Qiaobing,

Unfortunately the Host Name parameter has already been defined to
have strict RFC1123 Section 2.1 "host name syntax."  This is not
a URL (which would have even worse security implications than host
name already has).

IMO any approach which doesn't relay upon strict coordination between
multiple-NATs will open up multi-homed SCTP associations to all manner
of attacks.

--brian

On Wed, 04 Dec 2002, Qiaobing Xie wrote:

> Hi, La Monte,
> 
> (cc'ing this to tvswg list... this is more than implementation I think)
> 
> ...
> > I'm not convinced that we have an immediate and burning need for work
> > on multi-homed SCTP support behind multiple NAT boxen.  I'll not go so
> > far as to say that work on "Inter-NAT SCTP Coordination Protocol"
> > would be a BAD idea.  I just think that the SCTP community has more
> > important work right now.
> 
> I don't think I can speak for the SCTP users, though :-) For those companies who
> are currently looking at deploying SCTP for their services (I hope there are) and
> their infrastructure already contains multiple NAT/middle boxes, this becomes an
> "immediate and burning" need.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Qiaobing Xie | 5 Dec 2002 03:59

Re: Re: Multihoming with NAT

Hi, Brian,

"Brian F. G. Bidulock" wrote:
......
> Unfortunately the Host Name parameter has already been defined to
> have strict RFC1123 Section 2.1 "host name syntax."  This is not
> a URL (which would have even worse security implications than host
> name already has).

I don't think we should hang ourselves under that definition if in the future
someone comes up with a legitimate use of that TLV but requires a different "name"
syntax. Also, a solution may be found without relying on that TLV at all.

> 
> IMO any approach which doesn't relay upon strict coordination between
> multiple-NATs will open up multi-homed SCTP associations to all manner
> of attacks.

Agreed. Any solution must address security issues, just as we are reminded
constantly by IESG  :-)

-Qiaobing
Permalink | Reply | 0 comments |
headers
Williams, Jim | 5 Dec 2002 20:05
Favicon

"DO IT RIGHT", or "DON'T DO IT AT ALL"

The subject under discussion here is transforming
TCP into a record aligned transport to allow receivers
to do some level of ULP processing prior reassembly
of the TCP stream.  The specific goal is to enable
an RDDP protocol to directly place incoming
data even if TCP segments arrive out of order.

At least two drafts have been submitted which
propose mechanisms:

     draft-ietf-tsvwg-tcp-ulp-frame-01.txt [tuf] (expired)
and
     draft-culley-iwarp-mpa-00.txt [mpa]

In Atlanta I argued the case for "DON'T DO IT AT ALL".
The case being that TCP is a stream protocol and should
not be used otherwise.  SCTP is a record protocol and
should be used when a record protocol is needed.
And that "fixing" TCP rather than switching to SCTP
is the wrong architectural direction.

However in that aftermath of Atlanta I fear that
my argument is losing within the RDDP group, so I would
like to at least explore the alternative.

Under the heading of "DO IT RIGHT", both drafts
fall a bit short for the same reason.  The reason being
they both went to great lengths to minimize any changes
to TCP.  So I would like to explore the possibility that
changing TCP "just a little bit" may not be the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 5 Dec 2002 20:28
Favicon

Re: "DO IT RIGHT", or "DON'T DO IT AT ALL"

Jim,

Please go back to "DON'T DO IT AT ALL".  SCTP is the superior approach
here, resplendent with HOL blockage avoidance with streams and
multi-homing interface/network redundancy.  With very minor extension to
SCTP, DDP can be directly supported by SCTP adding performance gains in
the face of noise and failure that cannot be approached with TCP's
ordered pipe view of the world.

--brian

On Thu, 05 Dec 2002, Williams, Jim wrote:

> In Atlanta I argued the case for "DON'T DO IT AT ALL".
> The case being that TCP is a stream protocol and should
> not be used otherwise.  SCTP is a record protocol and
> should be used when a record protocol is needed.
> And that "fixing" TCP rather than switching to SCTP
> is the wrong architectural direction.

--

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock <at> openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
Permalink | Reply | 0 comments |
headers
David Robinson | 5 Dec 2002 22:15
Picon

Re: "DO IT RIGHT", or "DON'T DO IT AT ALL"

Williams, Jim wrote:

> The guiding architectural principal for "doing it
> right" is that the receiver should have some level of
> guarantee that it will always get record aligned TCP
> segments, and that any unaligned segments can and should
> be considered an error case, resulting in a closed
> connection.

Under the guise of "doing it right", I have to ponder if
alignment is the requirement or just a possible solution?

In a stream of data that ultimately can be reordered, resegmented,
and realigned the problem is how to find a header so we
can correctly place the data with minimal buffering. It
is clear that if we get the data portion before its header
we must either drop that segment or buffer it because
it cannot be placed correctly. The problem in an
unmodified stream is what to do with all the subsequent
data until the missing segment arrives to provide the
header necessary to reestablish framing.

One solution is to control alignment so there is a
reasonable expectation that there is a reasonable
expectation that the start of a subsequent segment
will be a header and framing can be reestablished.

If we are going to entertain "changing" TCP, how can
we do it with minimal invasiveness and most benefit?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Allman | 5 Dec 2002 21:01
Picon
Favicon

Re: Question on Limited Transmit (RFC3042)


> What is the transport-level mechanism to limit the use of "early
> retransmit?"  Assuming the simplest policy of using D-SACK that
> after TCP finds that "early retransmit" causes duplicate segment
> to be sent, it stops doing that.  It seems to me that several
> months later, a question will be asked why the "first strike"
> policy, why not "second or third strike?"  This probably means
> that a dynamic policy is required.  Is this complicated justified?

My own opinion is that the one strike scheme is nice and
conservative.  I might even buy something else that was easy to
implement like one mistake per X seconds or something.

I am not even sure that some more complex scheme would help here.  A
few schemes have been floated for adjusting the dupthresh.  But, I
think they require a bunch of samples to converge to doing something
reasonable.  And, sort of by definition a flow that needs something
like early retransmit is not going to be sampling all that fast.

So, I think something simple and conservative is fine here.

allman

--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
Permalink | Reply | 501 comments |
headers
Joe Touch | 5 Dec 2002 23:38
Picon
Favicon

Re: "DO IT RIGHT", or "DON'T DO IT AT ALL"

Williams, Jim wrote:
> The subject under discussion here is transforming
> TCP into a record aligned transport to allow receivers
> to do some level of ULP processing prior reassembly
> of the TCP stream.  The specific goal is to enable
> an RDDP protocol to directly place incoming
> data even if TCP segments arrive out of order.
> 
> At least two drafts have been submitted which
> propose mechanisms:
> 
>      draft-ietf-tsvwg-tcp-ulp-frame-01.txt [tuf] (expired)
> and
>      draft-culley-iwarp-mpa-00.txt [mpa]
> 
> In Atlanta I argued the case for "DON'T DO IT AT ALL".
> The case being that TCP is a stream protocol and should
> not be used otherwise.  SCTP is a record protocol and
> should be used when a record protocol is needed.
> And that "fixing" TCP rather than switching to SCTP
> is the wrong architectural direction.
> 
> However in that aftermath of Atlanta I fear that
> my argument is losing within the RDDP group, so I would
> like to at least explore the alternative.

I'd say "DON'T BOTHER AT ALL". Here's why:

	1- anything that really does something useful
	is going to require EITHER a change to
(Continue reading)

Permalink | Reply | 1 comment |

Gmane