Subject: [Tsvwg] Comments about addip-sctp-05

From: [email-masked]
Date: Sat, 18 May 2002 21:44:53 +0300

Hi all!

	I have read the new version of the draft, and, as I use to do, I'll make tons of comments about it... :-)

	Let's go in order...

	- Section 3, first paragraph. It says that there are 8 new parameters, but in reality only 6 are defined. I cannot believe that this has been there since so long time ago... 8-O

	- Section 3: "- Dynamic deletion of IP Addresses to an association". Should it say "from"? :-/

	- Section 3.1.1: I see that finally the address appears as I liked :-). However, the "Reserved" field still appears in the text below the figure of the chunk...

	- Section 3.2, Table 3: Minor comment. The name of the Parameter 0xC005 is "Success Indication" and not "Success report" as appears in the table.

	- Section 3.2.6: Excuse me, but, shouldn't it be "adaptation" instead of "adaption"? I don't remember which was the final decision... :-/

	- Section 3.3.4. This new Error Cause is to be used when we unexpectedly receive the "next correct ASCONF-ACK"(*). However, now, rule D0 has changed, and it does not require the received ASCONF-ACK to be the next one. Why this change? What if the network duplicates packets? :-/

	(*) If we haven't sent the ASCONF yet, how can the received ASCONF ACK be "correct"? :-)

	- Section 4.1, A2): "All serial numbers are defined to be initialized at the start of the association to the same value as the Initial TSN and are incremented by one." I think that something like "every time a new ASCONF chunk is created" would make the sentence clearer. By the way, what do you mean by "All"?

	- Section 4.1, A9): Typo "If the peer responds to *a* ASCONF...". Also, "... with an unrecognized chunk type", shouldn't it be something like "... with an ERROR chunk reporting that it did not recognize the ASCONF chunk type"? Otherwise it seems that it is the peer who is sending us a chunk we don't recognize... :-)

	- Section 4.1, last Note: In think this is a typo "... and enter a CLOSED state...". I imagine that it should be "... and enter in the CLOSED state..."

	- Section 4.2, L2): Now the Address Bytes field does not exist any more... :-/ It should say the Address parameter instead...

	- Section 4.2, V2): There is a mention here to the INIT ACK chunk that I don't understand... I hope the problem is not mine :-). I think it should say ERROR, but I don't know...

	- Section 4.2, V3): Now the Correlation ID is part of the parameters... The paragraph should be updated...

	- Section 4.3, D4: Don't blame me for doing this comment :-). "... any datagrams that arrive before the ASCONF-ACK destined to the IP address being deleted MUST be considered part of the current association."... Well, only if they come from the right source IP address...

	- Section 4.3.1: What would happen if the ABORT arrives later than the ASCONF-ACK? D4 does not apply here, so I guess that we would abort the association... Actually this situation makes more sense than the one avoided by D4, since only one packet is reordered instead of two... I don't know if we could do anything to avoid this situation... :-(

	- Section 5: I *think* that this is what I was thinking when speaking about addresses of one side of an association, endpoint or host. However, I have some problems to understand several paragraphs... :-(

	Is there any different between IPN and IPn? This confuses me sometimes... :-/

	In the first note ("do not confuse..."), why "the subset selected must always be the whole set"?... Moreover, "selected" for what? sE? and which "set"? H? It is like only one sock-endpoint could exist inside H for a given port... I don't understand this... :-(

	On top of page 22: "- contains more than one Element where..." More than one? Why? I understand that if Addr(sE) = {Wildcard} then there can be only one, but if Addr(sE)<> {Wildcard} I think there can still be only one... (besides, why "Element" with upper case?)

	In the next paragraph, "While establishing an association A between endpoints sE' and sE''...", "endpoints"? shouldn't it be "sock-endpoints"?

	Right after this, "If Addr(sE') is the {Wildcard} then Addr(sE',A) is a subset of H'", a "subset"? If we are using the wildcard, aren't we using *all* the addresses of H'?

	A little bit later, in the middle of the page, "Addr(sE,A) thus describes the set of IP addresses of E used for A", "E"? shouldn't it say H?

	In the 1., I fail to understand what is written after the "... thus true for H' and H''". I think that the "Therefore Addr(sE') and Addr(sE'') are known" should be something like "Therefore, we can define Addr(sE') as the set of addresses used by sE' even if there is no association established yet". I don't understand the next sentence... :-/ Unless it means something like "Thus Addr(sE') can represent the addresses to which sE' is bound"...

	In page 23, at the middle-top area of the page, "If Addr(sE') is the wildcard then Addr(sE',A) is a subset of H'"... ???... If Addr(sE') is the wildcard, doesn't it mean that it uses *all* the addresses of H? Besides, if we have created an association A having that sock-endpoint, isn't Addr(sE',A) equal to H?

	In R2, at the end, I guess that "Port(E)" should be "Port(sE)" instead...

	In R3, "S'" is not explicitly defined, but I think that it should be "S"... :-/

	In R4, "If Addr(sE) = {*} then any address of Addr(sE,A) can be removed anytime"... I think this is right *in theory* because if Addr(sE) = {*} then Addr(sE) is always equal to Addr(sE,A). But if we don't tell the peer that we are not using any more the removed address, we will answer with ABORTs to its datagrams directed to that address. Thus, it is wrong *in practice*... A Note might help here... :-/ (by the way, R4 is the only place where {*} is used... Everywhere else we have {Wildcard}... maybe it is better not to define {*} at all... :-))

	I think that the comment of R4 about the difference when using wildcard or not, also applies to R5.

	In the last paragraph of section I don't understand what "... the selection for S'" is...

	Some typos of section 5:

	- There are several "*an* sock-endpoint"... I have seen two of them in page 21...

	- Second paragraph of page 22: "disjoin".

	- Last paragraph of page 22: "Replace S' by a subset of S' *by* some limitation"... :-/ I think that "due to" or so should be used instead... Later, in this same paragraph, there is a ";" that should probably be a ".".

	- In the "else" at the end of page 23. "form" should be "from".

	In general, about section 5, I think that the main point of the section is leaving clear that Addr(sE,A) is not always equal to Addr(sE). The notation used should be clearly defined at the beginning of the section... For example, I think that "S" is exactly the same as Addr(sE,A) but I'm not sure...

	And the last and main question: which is the real difference between the "sock-endpoint" defined here and the endpoint defined in RFC 2960?	Which one is at a lower level?

	I would appreciate your comments, especially about section 5...

	Thanks!

	BR Iván Arias Rodríguez

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

---

From: Laurent Glaude <[email-masked]>
Date: Thu, 23 May 2002 11:35:37 -0400

Ivan,

I agree with you, mostly. I too find section 5 confusing, even though I *think*, like you, that it is explaining things in the "socket view".

My interpretation is that the intention expressed is to have the same type of functionnality / restrictions than with TCP. As an example, single-homed SCTP and TCP should have the same restriction that once a socket is bound to <ip, port>, no other socket can be.

Note that as posted earlier, there are exceptions with  the SO_REUSEADDR socket option. Stevens' "Network Programming"  book (pgs 194-197) explains four different purposes of the SO_REUSEADDR option.  However, SCTP supports multi-homing and does not support multicasting, so only the case of restarting a listening server may apply IMHO.

Now if we look at multi-homed SCTP, my interpretation is that the same rules apply, except that now instead of looking at a socket bound to <ip, port> , it is now bound to < {ip1, ..., ipN}, port >.

Comments?

-Laurent

--
Laurent Glaude
Software Engineer, Performance Technologies
[email-masked] - http://www.pt.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 23 May 2002 16:54:10 -0500

Laurent,

I don't believe that the draft has any business telling an implementation
what it can or cannot bind() to, not under what conditions.  Binding is
a completely local operation which has no impact on interoperability.  It
is only what active connections/associations are permitted to be formed
that counts.  For ADD-IP it should not matter what binding rules are applied
locally.  In fact, the conditions under which an implementation decides to
add or remove IP address or remove it from an active association are purely
a matter for the implementation adding or removing the IP address.  Only
the rule that a given pair of transport addresses cannot be involved in
more than one active association need be addressed.

As Stevens aptly demonstrates in "TCP/IP Illustrated," some BSD
implementations of TCP permitted a violation of TCP requirements by allowing
a connection to be formed while in 2MSL wait.  In fact the problem where
was not that SO_REUSEADDR was permiting multiple binds to the same transport
addresses, but that the implementation was subsequently permitting an active
connection to be formed in violation of this "Rule 2" (no transport address
pairing involved in more than one connection) by adding 128,000 to the last
segment number of the connection in 2MSL wait.

SCTP does not have this problem, because it has no timed wait.  SCTP will
reject a cookie while in shutting down, and after shutdown the transport
address can be made immediately avaialble (new Verification Tag distinguishes
between late-delivered messages from the old association and messages belonging
to the new association).  As a result, one could use SO_REUSEADDR with, say,
FTP servers to immediately reuse a port in a PORT command without having to
wait for the 2MSL timeout.

The only important part from a sockets perspective (or XTI for that matter:
XTI has the T_IP_REUSEADDR option) is refusing to permit a connection to be
attempted (i.e, INIT launched) for a transport address pairing that is part
of a existing connection.

This later "Rule 2" condition is rather complicated for SCTP because of the
multihoming nature.  Launching an INIT only describes the local transport
address list an one remote transport address.  When the INIT-ACK is returned,
the peer might place a transport address in the INIT-ACK remote address list
that violates this "Rule 2" (it might reply with a transport address which
is already involved in another association).  Of course, the peer would not
be smart to do this, however, it is possible.  This has made much of the
COOKIE ECHO rules (tie tags and the like) very complicated.

An SCTP implementation always needs to check that the pairing of local and
remote transport addresses follow this rule and uniquely describe an
association before establishnig an association, both when launching the
INIT-ACK and when launching a COOKIE-ECHO.  In this sockets interface this
occurs before a connect(2) or accept(2) call succeeds and the socket is
placed into the established hashes.

Because of this, there is no need for any imposed binding (or listening)
rules imposed on an implementation.  The established connection rule is
sufficient.

I propose that the Implementor's Guide remove the binding/listening rule
from RFC 2960 because it has no bearing on interoperability or, for that
matter, operation of the protocol whatsoever.  I propose that mention of
"binding" and "listening" be removed from the ADD-IP draft, unless only
used as a non-required example.

--brian

On Thu, 23 May 2002, Laurent Glaude wrote:

> Ivan,
> 
> I agree with you, mostly. I too find section 5 confusing, even though I
> *think*, like you, that it is explaining things in the "socket view".
> 
> My interpretation is that the intention expressed is to have the same type
> of functionnality / restrictions than with TCP. As an example, single-homed
> SCTP and TCP should have the same restriction that once a socket is bound to
> <ip, port>, no other socket can be.
> 
> Note that as posted earlier, there are exceptions with  the SO_REUSEADDR
> socket option. Stevens' "Network Programming"  book (pgs 194-197) explains
> four different purposes of the SO_REUSEADDR option.  However, SCTP supports
> multi-homing and does not support multicasting, so only the case of
> restarting a listening server may apply IMHO.
> 
> Now if we look at multi-homed SCTP, my interpretation is that the same rules
> apply, except that now instead of looking at a socket bound to <ip, port> ,
> it is now bound to < {ip1, ..., ipN}, port >.
> 
> Comments?
> 
> -Laurent
> 

-- 
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 ¦

---

From: Randall Stewart <[email-masked]>
Date: Fri, 24 May 2002 10:00:53 -0500

Ivan:

Ok, after a long delay ... I have decided to have
a read of your long set of comments ... source of the
document in hand so I can make changes :>

>         - Section 3, first paragraph. It says that there are 8 new parameters, but in reality only 6 are defined. I cannot believe that this has been there since so long time ago... 8-O

ok I will get this one fixed :> .. it is amazing the strange
little things that slip through...

>         - Section 3: "- Dynamic deletion of IP Addresses to an association". Should it say "from"? :-/

ok.. it does now :>

>         - Section 3.1.1: I see that finally the address appears as I liked :-). However, the "Reserved" field still appears in the text below the figure of the chunk...

opps... I have fixed it now.. good catch..

>         - Section 3.2, Table 3: Minor comment. The name of the Parameter 0xC005 is "Success Indication" and not "Success report" as appears in the table.

got it.

>         - Section 3.2.6: Excuse me, but, shouldn't it be "adaptation" instead of "adaption"? I don't remember which was the final decision... :-/

Got all 4 occurances :>

>         (*) If we haven't sent the ASCONF yet, how can the received ASCONF ACK be "correct"? :-)

I have been worried about this packet duplication in the network
as well. I think this paragraph and D0 needs to be changed to something
like:

"
    This error is to be included in an ABORT that is generated due
    to the reception of an ASCONF-ACK that was not expected but
    is larger than the current sequence number
    (see <xref target="genrules"/> Rule D0 ). Note that a 
    sequence number is larger than the last acked sequence
    number if it is either the next sequence or no more than
    2^^31 greater than the current sequence number.
"

Sorry about the XML X-ref ... it will turn into a ref to 4.1 ...

And D0 we can change to something like:

<t hangText="D0)">
    If an endpoint receives an ASCONF-ACK that is greater than
    or equal to the next sequence number to be used
    but no ASCONF chunk is outstanding the endpoint MUST 
    ABORT the association. Note that a sequence number is
    greater than if it is no more than 2^^31-1 larger than
    the current sequence number (using serial arithmetic).
</t>

>         - Section 4.1, A2): "All serial numbers are defined to be initialized at the start of the association to the same value as the Initial TSN and are incremented by one." I think that somethin…

How about:
<t hangText="A2)">
    A serial number should be assigned to the Chunk. The serial
    number should be a monotonically increasing number. The serial
    number SHOULD be initialized at the start of the
    association to the same value as the Initial TSN and 
    every time a new ASCONF chunk is created it is incremented
    by one after assigning the serial number to the newly created
    chunk .
</t>

>         - Section 4.1, A9): Typo "If the peer responds to *a* ASCONF...". Also, "... with an unrecognized chunk type", shouldn't it be something like "... with an ERROR chunk reporting that it did…

Ok it now reads:

<t hangText="A9)">
    If the peer responds to an ASCONF with an ERROR chunk reporting
    that it did not recognized the ASCONF chunk type,
    the sender of the ASCONF MUST NOT send any further ASCONF chunks and 
    MUST stop its T-4 timer. 
</t>

>         - Section 4.1, last Note: In think this is a typo "... and enter a CLOSED state...". I imagine that it should be "... and enter in the CLOSED state..."

How about:

"and enter into the CLOSED state"

>         - Section 4.2, L2): Now the Address Bytes field does not exist any more... :-/ It should say the Address parameter instead...

Thanks.. I actually caught that one when I converted to XML :>

>         - Section 4.2, V2): There is a mention here to the INIT ACK chunk that I don't understand... I hope the problem is not mine :-). I think it should say ERROR, but I don't know...

yep.. a typo :-> ERROR is correct...

>         - Section 4.2, V3): Now the Correlation ID is part of the parameters... The paragraph should be updated...
How is:

<t hangText="V3)">
All error responses MUST copy the ASCONF-Request Correlation ID
field received in the ASCONF parameter, from the TLV being responded to,
into
the ASCONF-Request Correlation ID field in the response parameter.
Note that a TLV sent in an ASCONF-ACK MUST include the Correlation ID
from the incoming request parameter.
</t>

>         - Section 4.3, D4: Don't blame me for doing this comment :-). "... any datagrams that arrive before the ASCONF-ACK destined to the IP address being deleted MUST be considered part of the cu…

So here I am not sure what you suggest... do you want a wording
change?  I agree with your comment.. but this is part of the
base SCTP .. the datagram must be from the correct source transport
address.... If you want a change please propose a wording so I can
get an idea of what you want...

>         - Section 4.3.1: What would happen if the ABORT arrives later than the ASCONF-ACK? D4 does not apply here, so I guess that we would abort the association... Actually this situation makes mo…

Why would the abort coming later cause the association to be
aborted? Once the ACK is processed the address is NO LONGER a
part of the association. As such the ABORT is itself OOTB. The
implementation
should not find the old association...

>         - Section 5: I *think* that this is what I was thinking when speaking about addresses of one side of an association, endpoint or host. However, I have some problems to understand several pa…

I will try to respond here.. But I want to be clear that the MAJORITY of
this text comes from Michael Tuexen. Michael was trying to capture
a MATHAMATICAL description of a SCTP endpoint etc... I added just
a few wordsmitthing so he may want to respond here...

>         Is there any different between IPN and IPn? This confuses me sometimes... :-/

There is only one place I can find IPN and that is the line:

    A host is a set of IP addresses H={IP1, ..., IPN}

I will change this to IPn for consistency... Michael, I do think
this is a typo?.. let me know if I am wrong here...

>         In the first note ("do not confuse..."), why "the subset selected must always be the whole set"?... Moreover, "selected" for what? sE? and which "set"? H? It is like only one sock-endpoint…

Yes I think Michael and Qiaobing were indicated selected into sE.

Michael.. I think you may need to propose some clearification here. I
will leave it untouched ... (if you would like let me send you the
xml .. send me a email offline and I will do so).

>         On top of page 22: "- contains more than one Element where..." More than one? Why? I understand that if Addr(sE) = {Wildcard} then there can be only one, but if Addr(sE)<> {Wildcard} I thin…

Maybe this should be "contains one or more Elements where Addr(sE) ..." 

Michael? Objections... again I will let you do the changing...

>         Right after this, "If Addr(sE') is the {Wildcard} then Addr(sE',A) is a subset of H'", a "subset"? If we are using the wildcard, aren't we using *all* the addresses of H'?
I will let Michael have the authoritative answer here but my guess is
that:

A) sE is what exists BEFORE the association is setup...
and
B) it becomes a subset of H' the minute it is created... it is ALL
   of them.. but an instant later an address could be added so it
   is truely a subset.. it just happens that it is a subset that is
   ALL at the moment of creation.. Michael is this correct or is it
   a typo here?

>         A little bit later, in the middle of the page, "Addr(sE,A) thus describes the set of IP addresses of E used for A", "E"? shouldn't it say H?

Not sure... Michael maybe this should be H.... typo per chance?

>         In the 1., I fail to understand what is written after the "... thus true for H' and H''". I think that the "Therefore Addr(sE') and Addr(sE'') are known" should be something like "Therefore…

Michael.. I am punting on this one :> have at it :-0...maybe a proposed
clearification (which I will let you add to the xml... I have decided
to email it to you offline.. after I commit my earlier changes to
cvs).

>         In page 23, at the middle-top area of the page, "If Addr(sE') is the wildcard then Addr(sE',A) is a subset of H'"... ???... If Addr(sE') is the wildcard, doesn't it mean that it uses *all*…

I think this gets back to if an address is subsequently added to H it
ISa
a sub-set .. Michael?

>         In R2, at the end, I guess that "Port(E)" should be "Port(sE)" instead...
yep.. this one I will change . Michael you can undo it if you disagree

>         In R3, "S'" is not explicitly defined, but I think that it should be "S"... :-/

Michael.. I will punt on this one :>

>         In R4, "If Addr(sE) = {*} then any address of Addr(sE,A) can be removed anytime"... I think this is right *in theory* because if Addr(sE) = {*} then Addr(sE) is always equal to Addr(sE,A).…
Michael, maybe it shoudl say "any address of Addr(sE,A) can be removed
via a ASCONF at anytime"  ???

>         In the last paragraph of section I don't understand what "... the selection for S'" is...

Ok michael I will let you comment change here.. I will address the typos
though..

>         - There are several "*an* sock-endpoint"... I have seen two of them in page 21...

this is because it was originally named endpoint but after a long
drawn out argument amongst the co-authors of this section we changed
the name and I failed to fix this... I did a global search and
replace on that...

>         - Second paragraph of page 22: "disjoin".
got it..

>         - Last paragraph of page 22: "Replace S' by a subset of S' *by* some limitation"... :-/ I think that "due to" or so should be used instead... Later, in this same paragraph, there is a ";" t…
ok I will take both of these..

>         In general, about section 5, I think that the main point of the section is leaving clear that Addr(sE,A) is not always equal to Addr(sE). The notation used should be clearly defined at the…
Ok  I will let Michael comment on the rest of this section :>

>         And the last and main question: which is the real difference between the "sock-endpoint" defined here and the endpoint defined in RFC 2960?     Which one is at a lower level?

The above I will let Qiaobing and Michael discuss with you.. there
was a long drawn-out discussion that I am not to sure what the
difference
is but I think there is one :->

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 May 2002 11:23:18 -0500

Randall,

See Stevens "TCP/IP Illustrated" description of FTP using PORT command on TCP.
THis is equally applicable to using FTP over SCTP.  The server must wait for
previous activity on the port to shut down (as part of a graceful shutdown)
before reusing the port specified in the PORT command.  Here a bind is needed
when a connect is not possible.  Thus SO_REUSEADDR in the common FTP case.

If one wishes to use SCTP for FTP (which is reasonable) then this capability
will need to be there.  I propose that the IG modify the statements in RFC
2960 so that this is permitted.  Otherwise FTP will not be able to use SCTP
for transport.

--brian

On Fri, 24 May 2002, Randall Stewart wrote:

> Laurent Glaude wrote:
> I don't think it is meant to explain the "socket view" but instead
> define mathamatically what is legal and not legal...
> 
> It shows that the following IS legal and may exist at the same time:
> 
> Host A   (IPA/B/C)                                         Host Z
> (IPX/Y/Z)
> 
> Endpoint1-IPA+Port:1111<-----------A1----------------->Endpoint2(IPX/Y/Z:Port
> 2222)
> Endpoint3-IPB/C+Port:1111<----------A2---------------->Endpoint2(IPX/Y/Z:Port
> 2222)
> 
> However the following is NOT legal
> 
> Host A   (IPA/B/C)                                         Host Z
> (IPX/Y/Z)
> 
> Endpoint1-IPA/B+Port:1111<-----------A1----------------->Endpoint2(IPX/Y/Z:Port
> 2222)
> Endpoint3-IPB/C+Port:1111<----------A2---------------->Endpoint2(IPX/Y/Z:Port
> 2222)
> 
> 
> In the above you cannot distingish a packet from Endpoint-2 with the
> destination address of IPB+Port:1111 as to who the packet belongs to.
> (Yes I know some would claim you could use the V-Tag but this IS NOT
>  its purpose and is not a legal thing to do). This is why the talk
> in the RFC about an address can only be in one endpoint is there... it
> is to keep the second scenario above from occuring...
> 
> 
> Yes..
> I agree that this would be the ONLY reason that I can think of
> that you would need SO_REUSEADDR... but it is COMPLETELY dependant
> upon HOW the implementation has setup its TCP/UDP model for SCTP. In
> our kernel implementation this is NEVER an issue since we keep
> two seperate pools of endpoints.. those that are connected or peeled
> off .. and thus not EVER capable of accepting/connecting to more
> places... AND then the pool of either UDP style EP's or the
> "connected" or "listening" tcp endpoints...
> 
> This means that SO_REUSEADDR is NOT needed .. if the server dies
> and then restarts.. it will NOT get an error when it trys to bind
> the address that it previously had... So in our case NO use of
> the SO_REUSEADDR is needed :>
> 
> correct.. and if one were to try to bind
> ip1,port and it is already bound in another placeit should fail...
> 
> R
> -- 
> Randall R. Stewart

---

From: Laurent Glaude <[email-masked]>
Date: Fri, 24 May 2002 09:18:32 -0400

Brian,

I agree 100%. Note that I was simply trying to understand / interpret the wording
of section 5 of add ip....

My implementation has the "traditionnal socket view" (as described in my previous
mail) as its default behaviour. However,  I do give users an option to bypass the
restrictions to let them do things like, say, start multiple clients from the same
local ip addresses & port as long as each client is connecting to a distinct peer.

-Laurent

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 23 May 2002 19:20:38 -0500

Hi, Laurent and Brian,

I see your point that section 5 is confusing in it current form. It is
too much mingled with socket-specific and impl-specific stuff (e.g.,
bindings, wildcarding, etc). 

ADD-IP is a generic fundamental extension to SCTP base protocol. It
should be made very clear in section 5 that the discussion there is only
relevant to a *particular group* of implementations that use a socket
abstraction layer AND use the specific type of wildcarding semantics.
For all other SCTP implementations section 5 becomes less relevant, but
ADD-IP is still fully applicable to those implementations.

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 24 May 2002 19:17:50 -0500

Hi, Ivan,

....
>         In general, about section 5, I think that the main point of the section is leaving clear that Addr(sE,A) is not always equal to Addr(sE). The notation used should be clearly defined at the…

I think "S" is the same as Addr(sE,A), too. No matter what we it, it is
simply one of the two logical termination ends of association "A", i.e.,
the association endpoint. In general *I think* we overdid the math
thing.

>         And the last and main question: which is the real difference between the "sock-endpoint" defined here and the endpoint defined in RFC 2960?     Which one is at a lower level?

I have to say that RFC2960 association endpoint (as defined in RFC2960
defs section) is at the *lowest* level, while a "sock-endpoint" can
spawn and own and manage multiple RFC2960 endpoints at any given time at
a higher level, such as at the socket abstraction layer if your
implementation does have one.

This was at least the original intention in RFC2960 when we decided to
use "endpoint" to represent the logical termination point of an
association. But I have to admit that, in RFC2960 text there are places
where we somewhat loosely used the term "endpoint" to also refer to
something more related to an implementation entity (especially when we
refer to how an association is setup).

regards,
-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 25 May 2002 18:43:48 -0500

Qiaobing,

Although I agree in general with your statements, I don't see section 5
as of any use to socket implementations either.

It would be far preferable if we could restrict ourselves to necessary
actions between peers and reduce section 5 to an example or implementation
notes only.  It might even be worth moving it into an Appendix.

--brian