Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00

["Brian F. G. Bidulock" <[e-mail]>]

Randall,

On Thu, 26 Jun 2003, Randall Stewart wrote:

> Sourabh Ladha (EED) wrote:
> 
> >Since the draft is for last call, I would be glad to hear
> >comments/clarifications on the following:
> >
> >(i) Consider a scenario, where a chunk is marked "abandoned" by the sender
> >(due to timed reliability or any other newcoming service definition).
> >Consider that the abandoned message was actually lost and that after having
> >marked "abandoned", the sender recieved the 4th missing report for this
> >chunk in a SACK (If sticking to the timed reliability service: if the
> >lifetime expires and is evaluated before the 4th missing report comes in).
> >For a PR-SCTP sender, the chunk is no longer outstanding and it does NOT
> >react (i.e. reduce its cwnd and so on) to this 4th missing report. Note
> >that both reliable and partially reliable messages can be carried in the
> >same association. Isnt congestion a property of the network. If so, then
> >shouldnt the PR-SCTP sender react to this 4th missing report of the
> >abandoned chunk by reducing congestion control state, however it does not
> >need to do a fast retransmit because the data is useless anyway. The draft
> >may point out, that if this is the case, th!  en it is being aggressive.
> >This may not be a corner case.
> >  
> >
> 
> We added for the above case:
> 
> F5) If a decision to "abandon" a chunk is made based on a
>       retransmission decision (e.g T3-Timeout or Fast Retransmit) the
>       appropriate congestion adjustment as specified in RFC2960 MUST be
>       made before any FORWARD TSN chunk is sent.
> 
> 
> But I can see it may not have been clear  enough. Maybe it should be 
> tightened up a bit ..
> 
> I think the main issue that people forget when looking at PR-SCTP is that
> just because the sender decides to abandon a chunk does NOT mean that all
> records of the chunk are dropped... in fact the sender MUST maintain some
> basic state on the chunk until the Cumulative-Ack point passes the chunk
> being abandonded... you don't have to maintain the data.. but you DO have to
> maintain things such as the TSN and strike count etc.
> 
> Maybe F5) should be reworded:
> 
> F5) If a decision to "abandon" a chunk is made, no matter how such decision
>     is made, the appropriate congestion adjustment MUST be made as specified
>     in RFC2960 if the chunk later would have been marked for retransmission
>     (e.g. T3-Timeout or Fast Retransmit).
> 
> 
> I will add the above change to the list of WG-Last call changes if no one
> objects...

The above sounds fine to me.

> 
> 
> 
> >
> >(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is
> >followed for every incoming SACK. Consider the scenario:
> >
> >A    1       B
> >-----lost	   
> >------2------>
> >     .	   	
> >     .	    	
> >     .	   	
> >------10----->
> >		    	
> >   dup ack 1   
> ><-------------
> >At this point of time A abandons 1. 
> >
> >From now on every dup-ack that comes in may generate a FW-TSN (with the
> >same cum TSN value of 2). 
> >
> >So in effect the sender:
> >(a) If the app still has data to send, reduce the effective payload by
> >    bundling repetative FW-TSN chunks in the packet.

> >(b) If the app has nothing to send currently, then either: 
> >	(i) it "MAY" delay the FW-TSN 
> >	(ii) or it may do a FW-TSN implosion if it is not delayed.
> >
> >Either way the issue is why to send the same FW-TSN over and over again?
> >For large congestion windows and high RTT paths this may cause trouble. 
> >
> 
> The reason you must send it until you get a SACK is that you don't know if
> the peer received it. A Fwd-TSN can be lost just like a data chunk.... A
> fwd-TSN is relatively small (smaller than a SACK).. I don't see how this is
> a big issue.. however I suppose we could modify the algorithm a bit and add
> a rule that states:
> 
> No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response to a
> SACK, the sender MUST NOT send more than one FWD-TSN every RTT.
> 
> This would then eliminate (ii) as an issue no matter how many SACK's the
> peer sends at you ...
> 
> 
> So how about changing F2) to state:
> 
>   F2) The data sender SHOULD always attempt to bundle an outgoing
>       FORWARD TSN with outbound DATA chunks for efficiency.
> 
>       A sender MAY even choose to delay the sending of the FORWARD TSN
>       in the hope of bundling it with an outbound DATA chunk. But no matter
>       if a sender delays a FORWARD TSN or sends one in response to a SACK,
>       a sender MUST NOT have more than one FORWARD TSN in flight per
>       round trip time.

I disagree.  The receiver is allowed to have more than one SACK in flight
per RTT, why is the sender not allowed to have one FORWARD TSN per SACK?

If the FORWARD TSNs cause problems, then so will the SACKs alone.

If there is a problem here, it is with the SACKs.

> 
> 
> >
> >
> >(iii) A forward TSN when recieved, updates and normally advances the
> >cum-ACK point. Now, if the chunks prior to that which were "abandoned" by
> >the sender are now recieved (they may have gone through delay or reordering
> >or some other cause), the reciever generates a "fake" dup-tsn report for
> >each of them. This is because the data chunk TSN recieved is behind the
> >current cum-TSN point at the reciever. Not only this adds extra SACK
> >traffic (carrying fake dup-tsn reports which are of no use to the sender)
> >but may also cause problems to certain algorithms (like blanton&allman's
> >"Using dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is not
> >a new transport protocol, it is an extension which very well resides with
> >RFC 2960. So either PR-SCTP reciever may be made capable of not generating
> >these "fake" dup-tsns or the other drafts (proposed or future) which use
> >dup-tsn reports should make an attempt to mention if they work well even
> >when PR-SCTP is enabled in an assoction.
> >  
> >
> 
> I am missing something here.. what do you mean by 'chunks prior to theat 
> which were "abandonded"'
> 
> Do you mean you abandonded it and then later it arrived...
> 
> or
> 
> Do you mean you abandoned a chunk 10 and then 8 and 9 arrived?
> 
> I think the first definition.. if I read your concern correctly .. is 
> what you mean..
> 
> I.e. I send a fwd-tsn(10)------->
> 
> and then some time later TSN-10 arrives.
> 
> First of all I think this is a real corner case and does not happen that
> often... basically the network must reorder and hold a packet for longer
> than the RTT time...  Yes I realize routing loops and such during
> convergance may cause this.. but it is a rare event. So I don't see how one
> extra dup report that is very rare is going cause an issue... now on to
> using the dup report.. as I said above, the sender MUST keep track of things
> until the cum-ack passes by.... Now looking specifically at blanton/allman
> it says something to the effect that "the sender MUST detect if the
> duplicate was retransmitted and if not (i.e. the network duplicated it) stop
> using the algorithm"... now this wording was made for network duplications..
> but it makes me think of a couple of things:
> 
> 1) In order to do the above, the cum-ack must NOT have passed the TSN..
> otherwise the sender would have no way to do the above.... which means you
> know you skipped it on the sender side... see my above statements on state
> :->
> 
> 2) The statement from blanton/allman would give the impression that the
> FWD'd chunk was a network duplicate thus disabling the algorithm..
> 
> So I think that:
> 
> a) the blanton/allman document already covers it
> and
> b) Once the cum-ack is past a point the blanton-allman document will have
>     little effect to PR-SCTP or just plain SCTP...
> 

I think is is the responsibility of these other drafts to consider
PR-SCTP, rather than visa versa.

> 
> 
> >
> >(iv) This is sort of a tangent. But, seems like there can be services which
> >remain in the framework of PR-SCTP but are aggressive and can motivate
> >unfriendly applications. I think, the draft dosent stress on the
> >REQUIREMENT for service definitions to be standardized within the IETF. 
> >  
> >
> You are  off on a tangent here IMO :> ... Please explain to me how PR-SCTP
> can motivate aggressive behavior? We have had long converstations on this
> list about this.. and a lot of off-line conversations as well with Mark
> Allman.. We have not been able to come up with a scenario for this.. I
> believe at one point (off-line) Phil Conrad offered to do some simulation
> work on this very issue.. and we could not come up with a valid scenario..
> the cwnd is being obeyed by the underlying SCTP stack... the rwnd as well..
> how does PR-SCTP make the sender more aggressive?
> 
> I would contend that PR-SCTP does just the opposite.. in times of congestion
> it reduces network traffic by taking data OFF the network... can you please
> specify something besides a vague statement? If you can come up with a valid
> scenario I am sure between Phil and I, we could do a simulation or study  to
> prove or dis-prove your contention of aggressiveness...
> 
> As to the service definition.. maybe you could connect this thought to the
> aggressive claim above? How would when a decision to abandon being made
> change the aggressiveness of PR-SCTP.. please consider also the clearication
> to F5) above .. I would like to know if this is possible that a definition
> could influence the on-wire performance.. I don't see how.. but as I said..
> I would be glad to try to find through simulation or test such a weakness...

I think we had this discussion already and came to concensus that this
discussion has much greater scope that PR-SCTP and PR-SCTP should not be
held up waiting for this greater discussion to occur or conclude.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[e-mail]    ¦ 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg