Subject: RE: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 10 May 2001 13:19:52 -0700

Ah, the mythical dentist...

I think that there is a good chance that the addip function will be
added, but not in this go-around.  Again, with 2960bis we're trying
to patch any holes, including most importantly the checksum.  We're
not adding any new functions (IPv6 was there in 2960).

Cheers,

Lyndon

-----Original Message-----
From: Kacheong Poon [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 1:12 PM
To: Qiaobing Xie
Cc: Jim Bound; Randall Stewart; [email-masked]; Ong, Lyndon;
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)

> A dentist who bought a pair of IPv6 machines wants to add a little
> redundancy to his office networking, he decides to put two interface
> cards to each of the machines and connects them with two separate sets
> of cables and then boots machines up. Now he starts an SCTP-based
> application on one of the machine to communicate with the other
> machine... The question is: will the SCTP be able to give him the
> networking redundancy he's been hoping for?

This exact question was asked by you, I remembered (or was it La Monte?),
at the Pittsburg IETF.  And I believe the conclusion was that the poor
dentist wouldn't get the redunduncy unless SCTP had the add/remove addr
capability.  To me, this is one of the major reasons why I think the
add/remove addr capability is needed, even though I don't think it is
a good idea to add new things to SCTP at this point.

							K. Poon.
							[email-masked]

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 10 May 2001 19:11:10 -0500

Kacheong Poon wrote:
> 
> I strongly recommend that we hold on putting this in the bis document.
> (Off topic, what does bis stand for and what does it mean?)  It is not
> clear to me that there is any consensus on how it works, even for v4.
> To put special rules which we don't have any real world experiment in
> a protocol specification is not a good idea.

I second Kacheong's opinion... 

And to my understanding, the only reason for issuing a bis on SCTP at
this point is to address the Adler-32 checksum problem. That is urgent
because it has huge deployment impact. But now it seems that we are
losing our focus.

(Have we reached a consensus on the checksum yet?)

regards,
-Qiaobing

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 10 May 2001 20:44:46 -0700

At 05:40 PM 5/10/2001, Lyndon Ong wrote:
>Folks,
>
>The expansion of the bis draft is partly my fault (BTW, "bis" is French 
>for "again", I think - the first time I saw "bis" being used was at ITU).

Again in French is "encore". I believe bis is Latin for second and ter is 
third.

>We need to reissue SCTP because of the checksum issue, and we should aim 
>at getting the reissue out quickly.  Beyond that, since it will be a new 
>RFC, we can also get some of the clarifications in to it that were 
>identified in testing, where these clarifications are generally agreed.

Yes to fixing the checksum issue, no to adding anything else to the main 
RFC. I'm wondering also since SCTP has documented multi-vendor 
interoperability if the next RFC with the fixed checksum shouldn't be a 
Draft Standard?

---

From: Randall Stewart <[email-masked]>
Date: Fri, 11 May 2001 13:23:23 -0500

> I second Kacheong's opinion...
I strongly disagree .. so does Jim Bound and I hope Steve Deering will
join us on this disagreement...

> because it has huge deployment impact. But now it seems that we are

It is not the only reason since we have agreed to fix the bakeoff issues
as
well.. and this WAS a bakeoff issue... i.e. address scoping.

> (Have we reached a consensus on the checksum yet?)

No I don't think so.. I have documented Fletcher-16 in the BIS but
this is NOT set in stone.. 

R

> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 May 2001 11:35:40 -0400 (EDT)

Erik,

I agree with the below.

/jim

On Tue, 15 May 2001, Erik Nordmark wrote:

> 
> > After much offline conversation.. the rules will move to a different
> > document.. one the NG group can hopefully spend a bit of time on....
> > possibly but for sure the addip?..... . Once we get the precise 
> > wording down, I think it will become a supplement
> > to SCTP (much like all of the supplements to TCP) until we go
> > for draft standard.. then I think it will get merged together...maybe :)
> 
> I think it would be quite useful for implementors to list the minimal 
> constraints on what must not be included as address parameters in the base
> spec.
> 
> I think this consists of just two rules:
>  - if neither the source address nor the destination address is a link
>    local address then link local addresses MUST NOT be included in
>    the address parameters. Any included link local addresses MUST
>    be on the same link as where the packet is sent.
>  - (above text with s/link/site/)
> 
> The reason it makes sense putting this in the spec is that
> without it folks can produce rather broken implementations which can
> cause interoperability problems when used in environments where
> e.g. site-local addresses are in use. Thus the interoperability problems
> might not appear immediately.
> 
>   Erik
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]
>

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 06:29:19 -0500

John:

Not that I consider an O/S to be a O/S without a MMU turned
on .. I call these things (such as windows 95/98 etc) a monitor :)

But I do tend to agree with you. If you have no O/S running and
it is all one big giant Monitor... then there is NO distinction
between kernel land and user land.. It then becomes as if
you are always in the kernel... 

This type of environment in some ways gives on more freedom.. i.e.
if you have a neighbor cache you have full access to it.

By the way, it is not a quibble... it is the whole point of Q's message
and it is very important to get the context of the situation 
straight...

R

[email-masked] wrote:
> 
> Qiaobing,
> 
> > As I explained in my earlier email to Jim, being in user-land also
> > includes the situation where every thing IS user-land, i.e., no
> > kernel/userspace separation as one can occasionally see in some
> > DSP-based small devices.
> 
> Not meaning to quibble, but I've always considered this kind of
> thing as everything being in kernel space.
> 
> Be that as it may, Randy's point about 'pure' userland implementations
> is correct.
> 
> br,
> John
> 
> ---

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: "Kiely, Gareth" <[email-masked]>
Date: Wed, 16 May 2001 09:47:50 -0700

(re-send because I've been advised that this is the new home for SCTP 
discussion - thanks Qiaobing - sorry for any duplication - Gareth)

Hi all,

Any implicit assumptions about how the spec is going to be implemented 
is going to put the credibility of the whole standard at risk.

We have particular reasons for wishing to keep our SCTP in user-land 
(including a requirement to support many operating systems) and are 
already developing products based on our user-land implementation which 
we expect to be around for ten years.

----------------------------------------------------------------------
Gareth Kiely            Principal Engineer            DataKinetics Ltd
Tel: +44 (0)1425 651329                        Fax: +44 (0)1425 655075
21 Green Lane       Fordingbridge       Hants       SP6 1HU         UK
---------------------------------------------------------------------- 

> From: Jim Bound [mailto:[email-masked]]
> Sent: 15 May 2001 19:05
> To: sigtran
> Cc: Kacheong Poon; Randall Stewart at work;
> [email-masked]; [email-masked]
> Do you really believe SCTP user space implementation will 
> exist 3 years
> from now or the telcos will buy a platform from a vendor who 
> has a user
> space SCTP implementation over a kernel based implementation.  A user
> space SCTP can never run as fast as a kernel based one.  
> Unless user space
> is defined as the VM370 arch was in the past or possibly MACH 4.0+.
> 
> thanks
> 
> /jim
> 
> On Tue, 15 May 2001, Qiaobing Xie wrote:
> 
> > Jim and others:
> > 
> > As far as the SCTP bis is concerned, I think we are getting 
> closer to a
> > conclusion on this issue.
> > 
> > One observation I'd like to make is: for the most part of this
> > discussion we seem to have overlooked the fact that SCTP is 
> NOT solely a
> > kernel protocol, and as a matter of fact there exists many user-land
> > implementations today and they will continue to exist in 
> the future. If
> > we put restrictions in the base spec to disallow certain behavior or
> > way-of-use only because it makes little sense or is hard to 
> implement in
> > the context of a kernel implementation, we may 
> inadvertently harm the
> > usability of the protocol in a broader scope.
> > 
> > regards,
> > -Qiaobing
> > 
> > Jim Bound wrote:
> > > 
> > > right???   are folks still writing code or what?  we are 
> saying we are
> > > going to jump into the transport space or have an extra 
> search on the
> > > common client in the kernel to whack the associations 
> address parameters
> > > because we don't want to adheer to Randys' rule set for 
> the NAT case in
> > > IPv6 where there are plenty of global addresses.  This is 
> plain wrong.
> > > I thought for sure the right thing would be done.  Oh 
> well. Very bogus.
> > > 
> > > /jim
> > > 
> > > On Mon, 14 May 2001, Kacheong Poon wrote:
> > > 
> > > > > Hmm, I have thought on this... and yes it might be 
> worth it... but
> > > > > in the case of v4 we also have NAT's murking up the 
> picture. In the
> > > > > case you illustrate... most likely if the sender does 
> send outside of
> > > > > his private address space a big ugly NAT will grab 
> and change his
> > > > > INIT addresses in at minimum the source address and 
> more likely
> > > > > it will strip all the TLV's out (yuck.. how ugly).
> > > >
> > > > I am not familiar with the latest NAT stuff.  So do 
> they also modify
> > > > transport level content now?  The problem we are 
> talking here is in
> > > > the address param list.  So the NAT has to understand 
> SCTP and how
> > > > to modify the address param list.  Is NAT really doing 
> this kind of
> > > > things now, say on the TCP bits?  I know they may 
> reject ECN bits,
> > > > but to modify them, I don't know.
> > > >
> > > > > IPV4 is convoluted by definition since many things 
> are broken with
> > > > > addressing aka NAT's etc.
> > > >
> > > > Well, even without NAT, we still need to solve the problem.  And
> > > > treating private v4 addresses as v6 site local will not 
> work here.
> > > >
> > > > > This does not remove control from the application... 
> If I only bind
> > > > > a link local address in my SCTP endpoint I will only 
> be able to
> > > > > talk to peer link-locals.. Same for site-local.. bind only a
> > > > > site-local and you only talk to peer site-locals... Its when
> > > > > you bind INADDR_ANY that this whole mess begins to 
> play out. In
> > > > > this case the user is punting, or for that matter if 
> the user makes
> > > > > a grevious error... having the rules in places does 
> exactly what
> > > > > Erik's statement above requests..... they may need to 
> be refined
> > > > > as Erik as pointed out by using source and 
> destination addresses...
> > > >
> > > > Using your wordings, the app loses its control if it tries to do
> > > > what your rules prohibit but may be perfectly legal in 
> a certain setup.
> > > > The SCTP stack should fail those special binding when 
> it is forming the
> > > > address param list.  That's the reason why I think we 
> should not put
> > > > the rule in the bis at this point.
> > > >
> > > > Glad to hear that we seem to have a conclusion on this issue.
> > > >
> > > >                                                       K. Poon.
> > > >                                                       
> [email-masked]
> > > >
> > > >
> > > >
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
>