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

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 22 Jun 2003 16:21:54 -0500

The chairs would like to initate a two week working group last call for the
PR SCTP draft commencing Monday 6/23/2003. Please direct all relevant
comments to this list.

Thanks!

Jon Peterson
NeuStar, Inc.

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

---

From: "Sourabh Ladha (EED)" <[email-masked]>
Date: Thu, 26 Jun 2003 17:50:51 +0200

Brian,

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

for the sake of arguement..

How can FORWARD TSN and SACK be compared? If you made this comparison only based on bytes then yes.
 
otherwise,
Each SACK being generated has hopes of delivering new information. The Forward TSNs (the case which I pointed out in the previous mail) generated are redundant. The only purpose they can serve is an improved reliability, which is again debatable. i.e. Is it a "correct" behaviour to improve reliability by duplicating information? I would say not.

-Sourabh

---

From: "Sourabh Ladha (EED)" <[email-masked]>
Date: Thu, 26 Jun 2003 21:09:25 +0200

> Yes... now you finally have a case that you would send the 
> fwd-tsn.. but 
> so what... it
> now still takes over 1/2 RTT for your FWD-TSN to arrive plus whatever 
> difference
> there is between sending 105 and 106... you have further 
> complicated your
> corner case in that the "abandon" time MUST be before the SACK for
> 106 arrives..  that is still a corner case.. routers generally
> don't hold packets to dump them on innocent transport protocols later 
> :-D they
> forward or drop the packets...

I dont understand..consider multihomed endpoints and the 
     primary path RTT (RTT1) << Alternate path RTT (RTT2)

Now your retransmission of TSN101 is going to experience 1/2 RTT2  but the forward TSN will experience 1/2 RTT1 + whatever delay you want to add.

I dont see this as what you call "real" corner case..moreover the "abandon" time "in this case" needs to be just before TSN106..but as I had previously said I wanted to look at the bigger picture..what if you have a higher cwnd say TSNs101-150 (as compared to TSNs101-106 in the example)..any dupsack coming after the "abandon" can trigger this forward TSN..so you have some range on "abandon" time..  

> 
> You are still talking about occurances that are rare.. aka a routing 
> reconvergance that
> lets the TSN101 get held somewhere and then later put to the 
> transport...

I dont think so...I am not necessarily referring to a routing instability phase..see above.

> I don't see building a strange corner case is justification for 
> changes... nor what
> the changes would be..

changes where? I wasnt proposing any changes on "this" particular point for PR-SCTP. The option always was for other drafts to consider it, if needed. 

> 
>(I look for others
> to chime in on this) we could add something 

Same here..To summarize, with PR-SCTP:
A reciever may at some point of time generate "fake" dup-tsn reports..but these cases may be called corner cases. And,

(i) should PR-SCTP attemp to address this.. (I too think that the answer to this is "no")
(ii) should drafts like blanton-allman duptsn draft consider such cases? 

-Sourabh