Subject: Re: [Tsvwg] End point and association Address conflict

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 06:31:27 -0500

Michael,

Please see comments below...

On Mon, 29 Apr 2002, Tuexen Michael wrote:

> > On Mon, 29 Apr 2002, Tuexen Michael wrote:
> > 
> > > Hi Brian,
> > > 
> > > if a host A has two IP-addresses IP' and IP'' and two associations
> > > from (IP', Port) to a peer (IP, Port) and (IP'', Port) to the peer
> > > (IP, Port) then 
> > > - host A has two IP-addresses
> > > - there are two end-points (IP', Port), (IP'', Port), each of them
> > >   uses only one IP address available at host A.
> > > This 'splits' (in your terminology) host A into two end points.
> > > The difference between IP addresses of the end point and IP addresses
> > > of the host is also the reason why it is valid to say
> > > - you MUST include all IP address of the end point in the INIT INIT-ACK.
> > > - you include a subset of all addresses of the host in the INIT INIT-ACK.
> > 
> > Why do you call (IPA, Port) one endpoint?  I view an endpoint as
> > half an association.  When two associations are formed from (IPA, Port),
> > there are two endpoints, not one.  When adding IPB and IPC and can
> > add IPB to one endpoint to form (IPB, IPA, Port) and IPC to another
> > to form (IPC, IPA, Port).  Why restrict this?  Particularly if that is
> > the way I would have bound them if IPB and IPC where available in the
> > first place?
> 
> [Tuexen Michael]  I think we are not using the same definition of end
> point. I'm using an abstract one based on RFC 2960. 
> Def.: An SCTP end point is a pair of a set of IP addresses and a port
>       number.

We all agree that an endpoint is a set of IP addresses and a port.  This
does not say that an endpoint is a unique set of IP addresses and a
port.  The cardinality of endpoints is not defined.

> This means, considering a server, I have only one end point for the
> server.

Your interpretation.  I have given an example where more than one server
can service the same endpoint.  This is typical and true even for TCP
(where multiple HTTP servers, for example, service the same IP/Port).

> Mulitple clients can conncect to the server.  These associations share
> the same end point.

Depending on how one views the cardinality of endpoints, these
associations can be viewed as connecting to different endpoints (even
though those endpoints were orginally bound to the same IP...IP/Port,
that is they had the same name).

> 
> This definition is in tune with the sentence "Two SCTP end points MUST
> not have more than one SCTP association between them at any time
> given" RFC 2960, page 13, defintion of SCTP association.

This gives no clues as to the cardinality of endpoints.  It only states
the cardinality of associations.

> 
> Using your definition as an end point is "half of an association" The
> sentence cited abover would be trivial.

The sentence above is what makes an endpoint half an association...

> 
> That is why I'm still thinking that my notion of SCTP end point is the
> one the authors of RFC 2960 had in mind.

Endpoint has had far more before RFC 2960.  An endpoint for
communication is the full duplex communications endpoint which occurs at
either end of the association.  When we bind and endpoint (give it a
name) we associate the IP...IP/Port with the endpoint.  When we connect
an association, we form a unique connection to another endpoint.  That
endpoint also has an name: IP...IP/Port, but we only contact it using
one IP address.

Just as with TCP, if we make an active connection from an endpoint only
(that is, we are not listening) then multiple sockets/streams can be
bound (named) with the same IP...IP/Port combination.  In fact, with
dynamic port allocation, IP/Port combinations are reused on TCP every
day between multiple connecting TCP endpoints (sockets/streams) that
have no clue that the magic port number `0' has yeilded the same IP/Port
combination as another TCP endpoint (socket/stream).

This is also the case of SCTP.  I have two sockets which I have bound
to IPA/IPB/Port`0'.  I connect from one socket to Host B and the
implementation assigns me port 10000.  I connect from the other socket
to Host C and the implementation also assigns me port 10000  (knowing
that there is no conflict because one IPA/IPB/Port10000 socket is
connected to HostB and the other IPA/IPB/Port10000 socket is connected
to HostC).  Now how can you call these the same endpoint?

--brian

> Best regards
> Michael

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ 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 ¦

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

---

From: Tuexen Michael <[email-masked]>
Date: Mon, 29 Apr 2002 12:53:33 +0200

Brian,

see my comments below.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Monday, April 29, 2002 11:01 AM
> To:	Tuexen Michael
> Cc:	Qiaobing Xie; Balani, Sandeep; 'Qiaobing Xie'; [email-masked]; [email-masked]; Khan, Mohammad; [email-masked]
> Subject:	Re: [Tsvwg] End point and association Address conflict
> 
> Michael,
> 
	[Tuexen Michael]  I think we are not using the same
	definition of end point. I'm using an abstract one based
	on RFC 2960. 
	Def.: An SCTP end point is a pair of a set of IP
	      addresses and a port number.
	This means, considering a server, I have only one end point
	for the server. Mulitple clients can conncect to the server.
	These associations share the same end point.

	This definition is in tune with the sentence
	"Two SCTP end points MUST not have more than one
	 SCTP association between them at any time given"
	RFC 2960, page 13, defintion of SCTP association.

	Using your definition as an end point is "half of an 
	association" The sentence cited abover would be trivial.

	That is why I'm still thinking that my notion of SCTP
	end point is the one the authors of RFC 2960 had in mind.

	Best regards
	Michael

> I have a host that talks to two other hosts.  IPA is a default and
> backup interface on this host.  IPB and IPC are dedicated high-speed
> interfaces for talking to HostB and HostC on an engineered network.
> Normally I would bind applications serving HostB to IPB as primary
> and IPA as secondary.  I would bind applications serving HostC to IPC
> as primary and IPA as secondary.  I have a default server which binds
> to IPA as primary.  All three servers listen on Port X.
> 
> With IPB and IPC down, the default A-server is listening on IPA Port X.
> When HostB connects, it spawns a B-server and forms the association
> (IPA, Port X) to HostB.  When HostC connects, it spawns an C-server
> and forms the association (IPA, Port X) to HostC.  When IPB becomes
> availble, the B-server wants it added to its association.  The C-server
> does not.  When IPC becomes available, the C-server wants it added to
> its association.  The B-Server does not.
> 
> So, unless the listener or connecter is actually bound to INADDR_ANY,
> there is no reason to force it to add IP addresses just because some
> other association happens to be engaged in an association with the
> same local addresses and port numbers.> 
> 
> --brian
> 
> 
> > 
> > Best regards
> > Michael
> > 
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CC SE 7    E-mail: [email-masked]
> > 
> > > -----Original Message-----
> > > From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> > > Sent:	Monday, April 29, 2002 8:50 AM
> > > To:	Qiaobing Xie
> > > Cc:	Balani, Sandeep; 'Qiaobing Xie'; [email-masked]; [email-masked]; Khan, Mohammad; [email-masked]
> > > Subject:	Re: [Tsvwg] End point and association Address conflict
> > > 
> > > Qiaobing,
> > > 
> > > Multi-homing is OPTIONAL.  Are you saying that a group of
> > > associations that are not multi-homed (single IP address
> > > in INIT), and on different IP addresses for the same host
> > > is somehow splitting the host into multiple end-points?
> > > I don't see how this is different than for TCP when the
> > > host has multiple IP addresses: each connection may be
> > > from a different IP address...  Please explain.
> > > 
> > > --brian
> > > 
> > > On Fri, 26 Apr 2002, Qiaobing Xie wrote:
> > > 
> > > > 
> > > > I don't think anything needs to be re-defined. We just need more
> > > > clarifications. To the implementor, a good add/delete-ip API semantics
> > > > might help to provide a safeguard against misuses. 
> > > > 
> > > > SCTP is different from TCP in that it allows a single endpoint to
> > > > associate with multiple peers (the "fan-out" config). But no matter how
> > > > many peers the endpoint is concurrently connected to, logically it is
> > > > _still_ a single endpoint. 
> > > > 
> > > > With this being cleared, it should not be hard to understand that it is
> > > > conceptually wrong to let a user apply add/delete-ip to only a subset of
> > > > the fan-out concurrent connections on that single endpoint. Because this
> > > > would in fact result in "splitting" the single endpoint into two
> > > > different ones. This is NEVER the intention of add/delete-ip - the
> > > > feature is meant to dynamically modify an endpoint without tearing down
> > > > all the associations it currently has; it is NOT meant to split a single
> > > > endpoint into two!
> > > > 
> > > > -Qiaobing
> > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock    > ¦ The reasonable man adapts himself to the ¦