Subject: RE: [Tsvwg] Comments about prsctp-00

From: [email-masked]
Date: Mon, 27 May 2002 16:00:06 +0300

> Ivan:
> 
> Once again I will get the document XML up and 
> go though this with your changes....
> 
> see below...

	snip...

> >         This first paragraph could be included at the end 
> of the section with the only modification of changing "INIT" 
> for "INIT ACK". This is because the section does not cover 
> the situation where the INIT sender does not support the 
> extension and the INIT ACK sender includes the new 
> parameter... You can always bundle the ERROR chunk right 
> AFTER the COOKIE ECHO chunk... :-/
> 
> I am confused by this comment.. what text do you want where? :> (maybe
> it is just me... I have changed the 3.3.2 to read:
> "
> 3.3.2 Receipt of Forward-TSN-Supported param in INIT
> 
>    When a receiver of an INIT detects a Forward-TSN-Supported 
> parameter,
>    and does not support the Forward-TSN chunk type, the 
> receiver SHOULD
>    treat this parameter as an invalid or unrecognized parameter and
>    respond to the data sender with an unrecognized paramater in the
>    INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
>    [4].
> "
> 
> What else do you want changed?

	Qiaobing got it perfectly. In his mail he exactly describes what I was speaking about...

> >         - Section 3.3.3, page 9: The previous comment 
> affects to this section as well... You would either receive 
> an Unrecognized Parameters parameter in the INIT ACK, or an 
> ERROR chunk after receiving the COOKIE ECHO, most probably 
> bundled with it (otherwise, if the COOKIE ECHO and ERROR 
> Chunks are reordered, the ERROR would be treated as an OOTB datagram).
> > 
> 
> Ok .. how about this:
> 
> "
> 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param
> 
>    When an SCTP endpoint that desires to use the FORWARD TSN chunk
>    feature for partially reliable data transfer receives an 
> operational
>    error from the remote endpoint (either bundled with the 
> COOKIE or as
>    a unrecognized parameter in the INIT-ACK), indicating that 
> the remote
>    endpoint does not recognize the Forward-TSN-Supported 
> parameter, the
>    local endpoint SHOULD inform its upper layer of the remote 
> endpoint's
>    inability to support partially reliable data transfer.
> 
>    The local endpoint may then choose to either:
> "
> 
> I think this capture the fact that you can get an error from one of
> the two sources aka INIT-ACK or bundled seperately with the COOKIE.
> 
> >         In the first case, 1) and 2) in section 3.3.3 make 
> sense (only changing "operational error" for "INIT ACK with 
> the Unrecognized Parameters parameter" would be required). In 
> the later case, the peer will have already processed the 
> COOKIE ECHO, and thus it will be already in the ESTABLISHED 
> state at the time of processing the ERROR Chunk (and then it 
> makes no sense to "end/continue the initiation process", 
> because the association is already established).
> > 
> 
> 
> I think no matter which way the peer sends you the error you must
> turn off the feature... 

	Yes, but the point is that if you receive the error inside an ERROR chunk, then you are not in the initiation process, since the association will be already established. So maybe just saying in 1) "end the initiation process or abort the newly established association..." could be enough. In 2), I would simply delete the "the initiation process"...

	snip...

> >         - Next paragraph in section 3.6: "... any messages 
> that carry a TSN earlier than or equal to the new cumulative 
> TSN point.". I'm not sure if this paragraph makes the 
> assumption that the messages are smaller than or equal to one 
> MTU and thus every SSN corresponds with a single TSN... :-/
> 
> No it does not make this assumption. pr-sctp procedures are on a
> TSN basis. This is ok when one thinks about it... consider
> a fragmented message
> 
> ---Msg 3k----TSN 7 BE=10/ TSN 8 BE=01
> 
> Now when it is time to retransmit one of a number things will
> be happening:
> 
> A) 7 needs retransmitting and 8 is received
> B) 7 and 8 need retransmitting
> C) 8 needs retransmitting.
> 
> If we are A.. .then when you advance everything according to the
> procedures your new FWD-TSN will be 8. Now this means that 
> when processing the FWD-TSN the sender must be careful to
> update its re-ordering queues very carefully... removing
> stray fluf that is hanging. It must examine the cum-ack point
> carefully and leave any unknown/undetermined things pending until
> it can look backwards and see the BE=10 and it knows it has
> everything...
> 
> 
> If we are B then BOTH should expire at the same time...
> 
> If we are C then FWD-TSN is 8 and 7 should get purged..
> 
> I don't see any problems here...

	Yes, this is what I thought it should be... However, the pointed paragraph somehow compares messages with TSNs... :-/

> > 
> >         Maybe, "... any fully received messages whose last 
> fragment has a TSN earlier than or equal to the new 
> cumulative TSN point." would be better... But this is not 
> really exact either... Let's make an example. If these have 
> been the last chunks sent:
> > 
> >         - (TSN: 100, Stream: 0, SSN: 10, Flags: B) RECEIVED 
> (and all the previous ones)
> >         - (TSN: 101, Stream: 0, SSN: 10, Flags: E) LOST
> >         - (TSN: 102, Stream: 1, SSN: 20, Flags: B) LOST
> >         - (TSN: 103, Stream: 1, SSN: 20, Flags: E) RECEIVED
> >         - (TSN: 104, Stream: 0, SSN: 11, Flags: BE) RECEIVED
> > 
> >         Then, so far, the cumulative TSN is 100. If SSN 10 
> of Stream 0 must be dropped, then the new 
> Advanced.Peer.Ack.Point would be 101. However, SSN 11 of 
> Stream 0 can be now delivered to the upper user (even though 
> it is not covered by the new cumulative TSN point).
> 
> this is why the peer must wait for the sender to tell it what 
> to fwd-tsn
> to
> only paying attention to the TSN number...  
> 
> In your example if we are skipping the message represented by
> TSN100/101 then the FWD-TSN will say 101.. this will leave
> 102 outstanding yet...
> 
> If both messages have expired then the FWD-TSN will be marked 
> with 104.
> Things in the reassembly queue would be purged to anything that was
> unknown. but the 104 would be released to read...
> 
> 
> > 
> >         The actions that must be taken upon receipt of a 
> FORWARD TSN are quite obvious, the hard thing is to express 
> them... :-)
> > 
> 
> Yep.. This is why the receiver must only pay attention to the TSN and
> not
> pay attention to the BE bits.. 

	Well, if any fragment of an SSN must be dropped, then, all the TSNs belonging to that SSN must be dropped as well... If the message is unordered, you don't have any other way to do this but checking the BE bits... But now that I think about it, you are right because all those TSNs will expire at the same time...

> >         - Section 4.1, TR3), page 16: Maybe instead of 
> saying that the lifetime parameter is set to "zero", it could 
> be said that it is set to "SCTP_LIFETIME_RELIABLE", as 
> previously defined...
> > 
> hmm I don't see that TR3) says anything about 0:
> "
>    TR3) Before assigning a TSN to any message, the SCTP sender MUST
>       evaluate the lifetime of that message.  If it is 
> expired, the SCTP
>       sender MUST NOT assign a TSN to that message, but 
> instead, SHOULD
>       issue a notification to the upper layer and drop the message.
> "

	In my version of the draft, this paragraph is TR4)... :-/

> do you mean TR1? And I would think TR2 has the same issue... Qiaobing

	I see that in TR1 it also uses the word "zero"...

	snip...

> >         - A final comment about the shape of the new 
> FORWARD TSN chunk. Have you thought about including gaps in 
> this chunk? probably yes. It is not a TSN what becomes stale, 
> but the whole SSN, so a list of (Stream ID, Dropped SSN) 
> could be useful as well. But this doesn't apply to unordered 
> messages... :-/ Maybe a simple list of TSNs that have been 
> dropped and that are not acknowledged in the received SACK 
> would be also useful... Probably the best way would be the 
> one used in the SACK chunks...
> > 
> 
> Qiaobing and I have debated this.. and after a lenghty bit of
> conversation we came to the conclusion that it was un-needed. One
> simply keeps what streams are pending re-ordering and that way
> you have a quick way to find all the ones that the TSN is smaller
> than the FWD-TSN point.

	Yes, but in situations as the one in the example below, the gaps could provide you with more information... The point is when something has been drop, and there are TSNs previous to those ones that are not dropped but haven't arrived yet either...

> >         In any case, the idea is that if these were the 
> last chunks sent:
> > 
> >         - (TSN: 100, Stream: 0, SSN: 10, Flags: B) RECEIVED 
> (and all the previous ones)
> >         - (TSN: 101, Stream: 0, SSN: 10, Flags: E) LOST
> >         - (TSN: 102, Stream: 1, SSN: 20, Flags: B) LOST
> >         - (TSN: 103, Stream: 1, SSN: 20, Flags: E) RECEIVED
> >         - (TSN: 104, Stream: 0, SSN: 11, Flags: B) RECEIVED
> >         - (TSN: 105, Stream: 0, SSN: 11, Flags: E) LOST
> >         - (TSN: 106, Stream: 0, SSN: 12, Flags: BE) RECEIVED
> > 
> >         At this point we receive the SACK [100: (3, 4); (6, 
> 6)] and we realize that SSNs 10 and 11 of Stream 0 have 
> become stale. Following the draft, one should send a FORWARD 
> TSN [101], and then nothing could be delivered to the upper 
> user. However, if we include gaps as done in the SACKs and we 
> send a FORWARD TSN [101: (3, 4)] (note that we include in the 
> gaps of the FORWARD TSN only the dropped TSNs that the peer 
> has not acknowledged), the receiver would know that TSN 105 
> has also been dropped and thus it can already deliver SSN 12 
> of Stream 0 to the upper user...
> > 
> 
> I see what you mean but this would make the implementation quite
> a bit more complex.. we were attempting to go for 
> simplicity... I don't

	You might be right... However, think that you can simply ignore the gaps both at the sender and receiver sides...

> think the gain is worth it.. because you will either get the ones
> inbetween

	Yes, but my concern is that in the situation of using PR-SCTP, few milliseconds will most likely make a difference. The receiver could be holding some SSNs for a short time, but enough to make them stale before those TSNs inbetween arrive (of the fwd-tsn)...

	From Qiaobing's mail:

> Yes, agree with Randy here. To report gaps or a full list of "dropped"
> TSNs in FORWARD TSN chunk will not be that useful because the 
> gaps from
> sender's view is not always the same as that from the receiver's view
> and what really matters is what the receiver sees (this is 
> fundamentally
> different from a SACK where what is reported in a SACK is the 
> receiver's
> view). 
> 
> For example, when the sender reports a list of "dropped" TNSs, some of
> the "dropped" TSNs might have already been correctly received 
> and passed
> on to the UPL. So whether the receiver will find the additional gap
> information useful is unclear.

	Well, you are just telling the receiver which TSNs will not retransmitted anymore... If you already got them, it does not matter. If you are still missing any of those dropped TSNs, then you should discard the user messages with at least one TSN dropped...

	But ignoring those gaps would not hurt you either (you would be exactly as we are now)...

	I know you won't like this, but you could even state if you support gaps (either at the sender or receiver side) inside the Forward-TSN-Supported parameter... Thus:

	- If the INIT sender supports everything, you may send gaps if you support them at the sender side, and state in your INIT ACK if you want the INIT sender to send you gaps.

	- If the INIT sender supports gaps at the sender side, you may state in your INIT ACK if you want it to send you those gaps. But you won't send gaps as it does not support them.

	- If the INIT sender supports gaps at the receiver side, the INIT ACK sender may send them...

	It would be another level of negotiation... :-/

	Just thinking at low voice... :-)

	Thanks for your reply!!

	BR Iván Arias Rodríguez

> or another fwd-tsn skipping... I would rather not have GAP-FWD-TSN's
> 
> R

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