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

From: [email-masked]
Date: Mon, 27 May 2002 17:30:20 +0300

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

	snip...

> >         - 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"? :-)
> 
> 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.
> "

	I think this is fine!

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

	Serial? Do you mean modular?

	snip...

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

	Maybe just something like: "... any datagram coming from the peer that arrive before..."

> >         - 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... :-(
> 
> 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...

	Sorry, you are completely right here... I don't know what I was thinking about when I made that comment... :-)

> >         - 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... :-(
> > 
> 
> 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...

	snip...

> >         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... :-(
> > 
> 
> 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).

	Yes please... this paragraph makes me know that a socket-endpoint is at a lower level (i.e., it has less addresses) than an endpoint... However, the idea seems to be the opposite, as per Qiaobing's comment... :-/

> >         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?)
> > 
> 
> Maybe this should be "contains one or more Elements where 
> Addr(sE) ..." 

	This would work for me...

> Michael? Objections... again I will let you do the changing...
> 
> >         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'?
> > 
> I will let Michael have the authoritative answer here but my guess is
> that:
> 
> A) sE is what exists BEFORE the association is setup...

	uhm... this is what Qiaobing stated... This makes things clearer...

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

	Could an endpoint use an address which is not part of the socket-endpoint? I don't think we should allow this... :-/

	I assume that both questions above are answer with a "yes"... :-)

	snip...

> >         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...
> > 
> 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 :->

	What I have understood so far is that a socket-endpoint is what listens to incoming INITs, i.e., it is the set of addresses that a new association will use. After this, we have an association between two *endpoints*, that could add/delete addresses, and thus use a SUBSET of the original socket-endpoint. Note, that IMHO an endpoint should not use an address that is not part of the socket-endpoint from which the endpoint originated.

	Moreover, if we plug/unplug network cards, a socket endpoint may change. If we add an address to a socket-endpoint, this address MAY be added to the associations whose "local endpoint" was originated from that socket-endpoint (i.e., associations belonging to that socket-endpoint). If an address is removed from one socket-endpoint, that address SHOULD be removed from all those associations (they may try to send an ASCONF. If it does not work, they may simply not use that address at all... the peer will notice that this address does not work anymore).

	Thus, I think that we have the next levels:

	- Host: All the addresses of the host.
	- Socket-endpoint: Part of the addresses of the host, plus a port number.
	- Endpoint: Part of the addresses of the socket-endpoint, plus the same port as the one of the socket-endpoint to which it belongs.

	In any case, I will wait for Michael's comments...

	Thanks for your comments!!

	BR Iván Arias Rodríguez

	PS: As Brian, I think that this section could be converted into an appendix...

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 28 May 2002 09:10:05 +0200

Ivan,

I'm currently doing some trips so my responses are a bit late. I will go 
through
the whole thread later this week when I have a better internet 
connection (currently
I'm using a free one at Munich Airport).

See further comments below.

Best regards
Michael

On Monday, May 27, 2002, at 04:30 PM, <[email-masked]> 
wrote:

> 	Sorry, you are completely right here... I don't know what I was 
> thinking about when I made that comment... :-)
>

I will do that. The think renaming a socket endpoint to a generalized
end point might help that people do not associate to much socket stuff
here.

> 	Yes please... this paragraph makes me know that a socket-endpoint 
> is at a lower level (i.e., it has less addresses) than an endpoint... 
> However, the idea seems to be the opposite, as per Qiaobing's 
> comment... :-/
>
> 	Could an endpoint use an address which is not part of the 
> socket-endpoint? I don't think we should allow this... :-/
>
> 	What I have understood so far is that a socket-endpoint is what 
> listens to incoming INITs, i.e., it is the set of addresses that a new 
> association will use. After this, we have an association between two 
> *endpoints*, that could add/delete addresses, and thus use a SUBSET of 
> the original socket-endpoint. Note, that IMHO an endpoint should not 
> use an address that is not part of the socket-endpoint from which the 
> endpoint originated.
That is true (if you take the wildcard as being a universal superset). 
That is why
we are doing a SUBSET selection.
Nothing is listening. It is a formal concept. We have to deal with the 
address scoping
stuff described in two other IDs. A sock-endpoint (or better generalized 
endpoint) knows
all possible addresses (including a wildcard, which means decide later), 
an endpoint
is the result of the address scoping stuff.
> 	Moreover, if we plug/unplug network cards, a socket endpoint may 
> change. If we add an address to a socket-endpoint, this address MAY be 
> added to the associations whose "local endpoint" was originated from 
> that socket-endpoint (i.e., associations belonging to that 
> socket-endpoint). If an address is removed from one socket-endpoint, 
> that address SHOULD be removed from all those associations (they may 
> try to send an ASCONF. If it does not work, they may simply not use 
> that address at all... the peer will notice that this address does not 
> work anymore).
That is OK, only the sequence of the operation is different. First 
delete it from all
endpoints, than from the generalized (sock endpoint) one, and after that 
from the host.
> 	- Socket-endpoint: Part of the addresses of the host, plus a port 
Or the wildcard address.
> 	- Endpoint: Part of the addresses of the socket-endpoint, plus the 
> same port as the one of the socket-endpoint to which it belongs.
That is the notion that is described in the ID, or at least that was 
intended.
> 	PS: As Brian, I think that this section could be converted into an 
This text is ONLY for being able to talk about things. These concepts do 
NOT have to
be implemented. If your implementation has no wildcard stuff, simply do 
not use it
in our description. All sock-endpoints then have explicit address lists. 
That is allowed,
and you can still derive what has to happen. So I have no problem, if 
the text goes into
an Annex or Appendix.
[email-masked]