Subject: Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-immediately-02: 19th March 2013

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 1 Apr 2013 23:29:45 -0700

Hi,

I support this draft.
Some minor questions I have are related to the following rule in the draft.
"the sending of a DATA chunk fills the congestion or receiver window."

1: I am personally curious about how much benefit we can get by this.
    If there's an analysis on this, I will want to see it in the reference.

2: Because this rule will be checked on every packet transmission, I
would like to know if the draft suggests to set I-bit everytime we
have a chance or there might be a case where we shouldn't.

Thanks,
--
Yoshifumi

On Tue, Mar 19, 2013 at 11:49 AM, Gorry Fairhurst <[email-masked]> wrote:
>
> This email announces the start of a working group last call for
> draft-ietf-tsvwg-sctp-sack-immediately-02.txt, "SACK-IMMEDIATELY Extension
> for the Stream Control Transmission Protocol". This document is now thought
> to be ready to proceed to be published as a PS. Please send any comments to
> the TSVWG list.
>
> The draft is available at:
> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately/
>
> The last call will run for TWO weeks, ending Friday 5th April 2013.
>
> Emails saying "I support" or "I don't support" publication are also most
> helpful in judging the WG consensus. Please let us know if this draft is
> useful and seems to provide the correct advice.
>
> James, David and Gorry
> (TSVWG Chairs)
> [email-masked]
>
>
>
>
>
>
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 2 Apr 2013 09:27:12 +0200

>    If there's an analysis on this, I will want to see it in the reference.
Hi Yoshifumi,

some simulation results are available at:
Improving the Acknowledgment Handling of SCTP
Rüngeler, I.; Tüxen, M.; Rathgeb, E. P.
Proceedings of the 4th International Conference on Digital Society (ICDS 2010), February 2010.
> have a chance or there might be a case where we shouldn't.
The sender could do it to switch off delayed SACK. However, this
might not be useful. Therefore, as stated, the sender should set it,
when he is waiting for an SACK.

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Tue, 2 Apr 2013 10:15:13 +0200

Hi,

I have read this draft and support it.

Regarding the issue below:

> when he is waiting for an SACK.

Could there be a way to phrase this in that style, to also make it more general than "a DATA chunk fills the congestion or receiver window" ?

I'm thinking about the case that draft-ietf-tcpm-rtorestart-00 addresses, of an application-limited sender that only has one SACK to expect and, in case it doesn't arrive, only a timeout to rely upon. Unless I'm missing some SCTP-specific detail here, it should also be beneficial to SACK early in this case (see fig. 1 in our draft).

This case would be covered by "when it is waiting for a SACK" but not by "fills the congestion or receiver window" (because both of these windows may be much larger than what the sender really transmits).

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 2 Apr 2013 10:58:06 +0200

> Could there be a way to phrase this in that style, to also make it more general than "a DATA chunk fills the congestion or receiver window" ?
Besides the very generic statement
(Whenever the sender of a DATA chunk can benefit from the
corresponding SACK chunk being sent back without delay...)
the ID lists some concrete situations (not a complete list).
I'm open to add another one, if you can provide some text...
> I'm thinking about the case that draft-ietf-tcpm-rtorestart-00 addresses, of an application-limited sender that only has one SACK to expect and, in case it doesn't arrive, only a timeout to rely up…
I'm not sure how the I-bit helps. I think you are focussing on retransmissions in case of packet drops.
Assume that the RTO is larger than the RTT + SACK.delay (if not, it is a mis-configuation, in
which setting the I-bit allows the sender to work around the problem), then one of two things happen:
* the packet is dropped and there is no SACK acking it. The sender will retransmit after RTO.
* the packet arrives and the corresponding SACK will arrive after an RTT or RTT + SACK.delay.
  In both cases, no retransmission will happen.

Am I missing something?
> This case would be covered by "when it is waiting for a SACK" but not by "fills the congestion or receiver window" (because both of these windows may be much larger than what the sender really tran…
I'm open for adding another scenario, where it helps. However, I did not understand you case
above...

Best regards
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 2 Apr 2013 11:09:13 -0700

Hi Michael,

> when he is waiting for an SACK.

OK. I just wanted to mention that in ideal equilibrium state, we might
need to set I-bit every packet since you'll get an ACK for 1 MSS,
which opens 1 MSS in cwnd.
But, as far as I can think this won't be a problem as the receiver has
a freedom to ignore it if it's necessary. (e.g. too much overhead)

BTW, we might want to set I-bit when we find there's no more packet to
send in buffer after sending a packet, even though
SCTP_SACK_IMMEDIATELY is not used.
Do you have any comment on this?

Thanks,
--
Yoshifumi

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 02 Apr 2013 22:46:24 +0200

Dear Gorry,

I have read the draft draft-ietf-tsvwg-sctp-sack-immediately-02 and I support 
it. As part of my work on CMT-SCTP, I have frequently made use of this 
extension both in FreeBSD SCTP in real Internet setups as well as in 
simulations. It is a quite useful and very simple extension to enhance the 
SCTP performance.

Tirsdag 19. mars 2013 18.49.20 skrev Gorry Fairhurst:
> draft-ietf-tsvwg-sctp-sack-immediately-02.txt, "SACK-IMMEDIATELY
> Extension for the Stream Control Transmission Protocol". This document
> is now thought to be ready to proceed to be published as a PS. Please
> send any comments to the TSVWG list.
> 
>   helpful in judging the WG consensus. Please let us know if this draft
> is useful and seems to provide the correct advice.
> 
> James, David and Gorry
> (TSVWG Chairs)
> [email-masked]

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

=======================================================================
 Thomas Dreibholz

 Simula Research Laboratory
 Simula Innovation AS, Network Systems Group
 Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway
 Mailing address:  P.O.Box 134, 1325 Lysaker, Norway
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://simula.no/people/dreibh
=======================================================================

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 02 Apr 2013 22:46:39 +0200

Dear Gorry,

I would like to express my support for the draft draft-ietf-tsvwg-sctp-udp-
encaps-14. It is a very useful extension to make use of SCTP in certain setups 
where SCTP is not possible otherwise, e.g. when blocked by firewalls or not 
supported by operating system kernels.

As part of my work on the sctplib userland SCTP implementation, I have also 
implemented UDP encapsulation in sctplib. I intensively used it in sctplib-
based RSerPool setups.

Fredag 22. mars 2013 12.19.40 skrev Gorry Fairhurst:
> draft-ietf-tsvwg-sctp-udp-encaps-14, "UDP Encapsulation of SCTP Packets
> for End-Host to End-Host Communication".  This document has completed an
> IETF LC and was updated after IESG review. This is now thought to be
> ready to proceed to be published as a PS by RFC-Ed. Please send any
> comments to the TSVWG list.
> 
> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-14
> 
> Summary of main changes:
> 
> * Clarification that the focus is on encapsulation between SCTP endpoints.
> 
> * UNSAF considerations added.
> 
> * Change from UDP checksum MUST be computed for SCTP/UDP/IPv6 to UDP
> checksum SHOULD be computed for SCTP/UDP/IPv6 to reflect recently
> changed UDP/IPv6 checksum handling, with rationale provided.
> 
> A diff between the version submitted to the IESG and the current version
> can be viewed using:
> http://tools.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-sctp-udp-encaps-07.txt&u
> rl2=draft-ietf-tsvwg-sctp-udp-encaps-14.txt
> 
> This shortened last call will end on Friday 5th April 2013.
> 
> Emails saying "I support" or "I don't support" publication with these
> changes are also most  helpful in judging the WG consensus.
> 
> Please note another running SCTP WGLC also below.
> 
> James and Gorry
> (TSVWG Chairs)
> [email-masked]
> 
> 
> 
> -------- Forwarded Message --------
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 3 Apr 2013 09:25:56 +0200

Hi,

I'd also like to express support. I read the draft and it looks good to me, and surely it's useful.

Cheers,
Michael

---

From: "Becke, Martin" <[email-masked]>
Date: Wed, 3 Apr 2013 07:47:15 +0000

Hi, 

I am fine with this version. 
Motivation is clear and the draft works for me. 
I support this. 

Martin

> Dear Gorry,
> 
> I would like to express my support for the draft 
> draft-ietf-tsvwg-sctp-udp- encaps-14. It is a very useful extension to 
> make use of SCTP in certain setups where SCTP is not possible 
> otherwise, e.g. when blocked by firewalls or not supported by operating system kernels.
> 
> As part of my work on the sctplib userland SCTP implementation, I have 
> also implemented UDP encapsulation in sctplib. I intensively used it 
> in sctplib- based RSerPool setups.
> 
> 
>> draft-ietf-tsvwg-sctp-udp-encaps-14, "UDP Encapsulation of SCTP 
>> Packets for End-Host to End-Host Communication".  This document has 
>> completed an IETF LC and was updated after IESG review. This is now 
>> thought to be ready to proceed to be published as a PS by RFC-Ed. 
>> Please send any comments to the TSVWG list.
>> 
>> A diff between the version submitted to the IESG and the current 
>> version can be viewed using:
>> http://tools.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-sctp-udp-encaps-0
>> 7.txt&u rl2=draft-ietf-tsvwg-sctp-udp-encaps-14.txt
>> 
>> Extension for the Stream Control Transmission Protocol". This 
>> document is now thought to be ready to proceed to be published as a 
>> PS. Please send any comments to the TSVWG list.
>> 
>> Emails saying "I support" or "I don't support" publication are also 
>> most  helpful in judging the WG consensus. Please let us know if this 
>> draft is useful and seems to provide the correct advice.
>> 
>> James, David and Gorry
>> (TSVWG Chairs)
>> [email-masked]

---

From: "Becke, Martin" <[email-masked]>
Date: Wed, 3 Apr 2013 07:54:05 +0000

Hi, 

I was also involved in the work Thomas mentioned and I can confirm that it is a useful extension. 

Martin

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas Dreibholz
Gesendet: Dienstag, 2. April 2013 22:46
An: [email-masked]
Betreff: Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-immediately-02: 19th March 2013

Dear Gorry,

I have read the draft draft-ietf-tsvwg-sctp-sack-immediately-02 and I support it. As part of my work on CMT-SCTP, I have frequently made use of this extension both in FreeBSD SCTP in real Internet setups as well as in simulations. It is a quite useful and very simple extension to enhance the SCTP performance.

Tirsdag 19. mars 2013 18.49.20 skrev Gorry Fairhurst:
>   helpful in judging the WG consensus. Please let us know if this 

 Simula Innovation AS, Network Systems Group  Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway  Mailing address:  P.O.Box 134, 1325 Lysaker, Norway

---

From: Michael Welzl <[email-masked]>
Date: Wed, 3 Apr 2013 11:42:07 +0200

Hi,

> I'm open to add another one, if you can provide some text...

See below -

> I'm open for adding another scenario, where it helps. However, I did not understand you case

My apologies, there are two issues with what I wrote:
1) writing about only one single packet was of course misleading - yes it is about this packet (the case where it's dropped), but it really has to do with the ACK of the preceding packet.
2) because of 1), in fact it was wrong to say that "this case would be covered by 'when it is waiting for a SACK' " because it's the preceding packet that would have to have the I-bit set. That makes it harder to come up with text, but I'll give it a try anyway. I suggest the following:

***
- leave the generic statement (Whenever the sender of a DATA chunk can benefit from the
corresponding SACK chunk being sent back without delay...) as it is
- in section 4.2, insert the following paragraph:

When a sender receives a SACK chunk, it re-arms the RTO timer, and the time at which this happens if affected by a delayed SACK chunk. If the last packet in a send window is lost, it will therefore be retransmitted later if the SACK chunk that was caused by the DATA chunk just before it is delayed. This can be avoided by setting the I-bit on the penultimate DATA chunk of the send window.

Item for section 5.1:
- The DATA chunk is known to be the penultimate DATA chunk of the send window.
***

The tricky bit here is the application-limited case. In case of a greedy sender, the "penultimate DATA chunk of a send window" is the DATA chunk just before the one that fills the congestion or receiver window, or the last DATA chunk altogether before the association is shut down. But in the application-limited case, one can never be sure how long an application pause is going to last... in my text above, I decided to leave this open by just saying "of the send window". This is perhaps not good - if you can fix this great, if you'd rather not even bother, just leave it out and forget it, that's fine by me too  :-)   it was just a suggestion. Anyway it's covered by the nice CFP-style phrase in your text that says: "Reasons for setting the I-bit include, but are not limited to, the following"  :-)

I hope I have made myself clear enough. If not, please do take a quick look at fig. 1 of http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-00 which probably explains it better.

Cheers,
Michael

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 02 Apr 2013 13:11:39 +0200

Dear Gorry,

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 02 Apr 2013 13:05:59 +0200

Dear Gorry,

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 4 Apr 2013 21:34:08 +0200

Hi Michael,

OK I understand the point. Just to double check: If draft-ietf-tcpm-rtorestart is used, the above is not necessary, right?
If that is right, wouldn't the right solution be to implement draft-ietf-tcpm-rtorestart-00? In both cases it would be
a sender side modification?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 4 Apr 2013 21:40:13 +0200

> a freedom to ignore it if it's necessary. (e.g. too much overhead)
That is a possibility. On the other hand, the receiver could set the
SACK frequency to 1 or the delay to 0 to get the same.
> SCTP_SACK_IMMEDIATELY is not used.
Why? It would definitely be possible...
> Do you have any comment on this?
Without the reason, I have only a general comment: The list provided
to indicate conditions to set the I-bit is not exhaustive. I expect
optimizations coming over time...

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 4 Apr 2013 21:57:18 +0200

> a sender side modification?

Yes and yes   :-)

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 4 Apr 2013 22:20:32 +0200

>> a sender side modification?
OK. Then I would prefer to leave it out of this document since it is neither the right solution
nor easy to implement (at least the application limited case).

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 4 Apr 2013 22:34:06 +0200

> nor easy to implement (at least the application limited case).

Okay, fine by me

Cheers,
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 05 Apr 2013 01:42:37 +0200

Hi Michael and all,

I have also read and support this draft.

In relation to the use case discussion I think that a potential use 
case, related to but not fully covered by RTO restart, is thin stream 
applications that send messages at a low rate (perhaps gaming control 
packets over a RTCWeb data channel or something similar). Here the I-bit 
could be useful to avoid delayed ACKs infalting the RTO and leading to 
reduced performance if a later message is lost.

Perhaps adding such a use case under 4.1 could be good to show that 
there are more than one use case also at the application level? Section 
4.1 almost gives the impression that the application use case for 
setting the I-bit is connected to the SCTP_SENDER_DRY_EVENT 
notification, which I guess is meant only as an example.

Another detail on 4.1. When from the perspective of the application, 
would it be better to say that the application sets the I-bit for a 
message (rather than the last DATA chunk of a message) as it is not 
really aware of the split into chunks?

Nit. In section 7, I guess "the SCTP_SACK_IMMEDIATELY flags can be set 
in the sinfo_flags field" should be "the SCTP_SACK_IMMEDIATELY flag ...".

BR,
Anna

---

From: Irene Rüngeler <[email-masked]>
Date: Fri, 5 Apr 2013 09:48:28 +0200

Hi,

I want to express my support for this draft and agree with the changes made after the WGLC.

Best regards

Irene
Am 22.03.2013 um 13:19 schrieb Gorry Fairhurst:

> draft-ietf-tsvwg-sctp-udp-encaps-14, "UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication".  This document has completed an IETF LC and was updated after IESG review. This is now thought to be ready to proceed to be published as a PS by RFC-Ed. Please send any comments to the TSVWG list.
> 
> * Change from UDP checksum MUST be computed for SCTP/UDP/IPv6 to UDP checksum SHOULD be computed for SCTP/UDP/IPv6 to reflect recently changed UDP/IPv6 checksum handling, with rationale provided.
> 
> A diff between the version submitted to the IESG and the current version can be viewed using:
> http://tools.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-sctp-udp-encaps-07.txt&url2=draft-ietf-tsvwg-sctp-udp-encaps-14.txt
> 
> Emails saying "I support" or "I don't support" publication with these changes are also most  helpful in judging the WG consensus.
> 
> draft-ietf-tsvwg-sctp-sack-immediately-02.txt, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol". This document is now thought to be ready to proceed to be published as a PS. Please send any comments to the TSVWG list.
> 
> Emails saying "I support" or "I don't support" publication are also most  helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice.
> 
> James, David and Gorry
> (TSVWG Chairs)
> [email-masked]
> 
> 
> 
> 
> 
> 
> 

*************************************
Dr. Irene Rüngeler
FB Elektrotechnik und Informatik

Fachhochschule Münster
- University of Applied Sciences -
Bismarckstr. 11
D-48565 Steinfurt

Fon: (49)02551 - 962561
Fax: (49)02551 - 962563
Mail: [email-masked]
www.fh-muenster.de/fb2/personen/mitarbeiter/ruengeler

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Apr 2013 13:40:19 +0200

On Apr 5, 2013, at 1:42 AM, Anna Brunstrom wrote:

> In relation to the use case discussion I think that a potential use case, related to but not fully covered by RTO restart, is thin stream applications that send messages at a low rate (perhaps gaming control packets over a RTCWeb data channel or something similar). Here the I-bit could be useful to avoid delayed ACKs infalting the RTO and leading to reduced performance if a later message is lost.
Hi Anna,

just to make sure that I understand your suggestion. On a thin stream the SACKs come back
after RTT + SACK.delay and not RTT. Doesn't this mean that there is no effect if
RTO.Min > RTT + SACK.delay?

Having RTO.Min < RTT + SACK.delay is a consequence of configurations no being in tune.
I have seen this in deployments. The only thing the sender can do it to set the I-Bit
to avoid all messages being retransmitted. I (personally) think this is a useful scenario,
but based on WG feedback I took it out. The reason was that the configuration should be
fixed. See
http://tools.ietf.org/rfcdiff?url2=draft-tuexen-tsvwg-sctp-sack-immediately-07.txt

However, do you have another scenario in mind?
> 
> Perhaps adding such a use case under 4.1 could be good to show that there are more than one use case also at the application level? Section 4.1 almost gives the impression that the application use case for setting the I-bit is connected to the SCTP_SENDER_DRY_EVENT notification, which I guess is meant only as an example.
You are completely right. Section 4.1 and 4.2 gives just examples. So I added to Section 4 the following:

The following two subsections provide a non-exhaustive list of examples.

OK?
> 
> Another detail on 4.1. When from the perspective of the application, would it be better to say that the application sets the I-bit for a message (rather than the last DATA chunk of a message) as it is not really aware of the split into chunks?
That is absolutely correct. What about

To avoid an unnecessary delay while waiting for such an event, the application
can request the setting of the I-Bit when sending the last user message
before waiting for the event. This results in setting the I-bit of
the last DATA chunk corresponding to the user message and is possible
using the extension of the socket API described in <xref target='api'/>.

> 
> Nit. In section 7, I guess "the SCTP_SACK_IMMEDIATELY flags can be set in the sinfo_flags field" should be "the SCTP_SACK_IMMEDIATELY flag ...".
Good catch! Changed in the CVS version.

Thanks a lot for you comments!

Best regards
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 05 Apr 2013 19:44:32 +0200

Hi Michael,

> RTO.Min > RTT + SACK.delay?
Not necessarily I think. If the thin stream traffic varies a bit in 
intensity SACKs may come back after RTT, after RTT + SACK.delay or at 
some time in between the two. The variability will inflate RTTVAR and as 
a consequence the RTO. So I was thinking this could be bad when a packet 
is actually lost, not that the problem was spurious retransmits.

But perhaps the span between a well configured RTO.Min and the possibly 
inflated RTO will not be large enough for it to be useful scenario.

> http://tools.ietf.org/rfcdiff?url2=draft-tuexen-tsvwg-sctp-sack-immediately-07.txt

I'm not surprised that you have seen RTO.Min < RTT + SACK.delay happen 
as in general it is not so easy to know what the RTT will be beforehand. 
Although I see the retransmission problem, I do not understand why this 
would result in ALL messages being retransmitted as the calculated RTO 
should be larger than RTO.Min if the SACKs come back after RTT + 
SACK.delay all the time?

> The following two subsections provide a non-exhaustive list of examples.

This will be fine I think, and is probably a better fix than coming up 
with new examples :-)

> using the extension of the socket API described in <xref target='api'/>.
This sounds much better I think.

BR,
Anna

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Apr 2013 20:55:49 +0200

On Apr 5, 2013, at 7:44 PM, Anna Brunstrom wrote:

> Not necessarily I think. If the thin stream traffic varies a bit in intensity SACKs may come back after RTT, after RTT + SACK.delay or at some time in between the two. The variability will inflate RTTVAR and as a consequence the RTO. So I was thinking this could be bad when a packet is actually lost, not that the problem was spurious retransmits.
> 
> But perhaps the span between a well configured RTO.Min and the possibly inflated RTO will not be large enough for it to be useful scenario.
OK.
> I'm not surprised that you have seen RTO.Min < RTT + SACK.delay happen as in general it is not so easy to know what the RTT will be beforehand. Although I see the retransmission problem, I do not understand why this would result in ALL messages being retransmitted as the calculated RTO should be larger than RTO.Min if the SACKs come back after RTT + SACK.delay all the time?
This about the sender using RTO.Min = 50ms, RTT = 10ms, SACK.delay = 200ms.
And consider a high HB rate which brings down the RTO to RTO.Min.
And I'm assuming a thin stream... (It a SIGTRAN setup, where the receiver is misconfigured).
> This will be fine I think, and is probably a better fix than coming up with new examples :-)
> 
Great. Thanks a lot for you comments!

Best regards
Michael

---

From: [email-masked]
Date: Mon, 8 Apr 2013 07:41:36 +0100

This emails concludes the WGLC period.  There was consensus to proceed
with publication (6 notes) of support) and no notes that suggested we
should not publish.

During the WGLC various comments were contributed and questions raised -
the authors should now use this list to work on updated text to fix these
issues and submit a new draft with a summary of changes.

Best wishes,

Gorry
(as TSVWG Co-Chair).

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 8 Apr 2013 10:40:19 +0200

> issues and submit a new draft with a summary of changes.
A new version has been submitted:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately

The differences can be view via
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-sack-immediately-03

Summary of changes:
* Grammar and spelling improvements.
* Text changes to improve clarity and readability.

So no technical changes were introduced.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Fri, 19 Apr 2013 08:20:17 -0400

Nishida-san:

Sorry for the later reply.. just catching up on my email. ;-)

in-line

> a freedom to ignore it if it's necessary. (e.g. too much overhead)

I am a little confused here on the above. If I get an ACK for
1 MSS, I then increment my cwnd (say by 1 MSS in Slow start) and 
also decrease my flight size by the amount acked, 1 MSS, which then
allows me to send 2 MSS. 

In CA if I can only send 1 MSS, then I am a situation where 1 RTT
is being sent per RTT. Which means my PBA will have increased one whole
cwnd and I again should be able to advance my cwnd by 1 whole segment… so
again 2 segments are ready to send… assuming I have them to send.

Where I don't have 2 full segments I could see the i-bit but I guess I
am missing the scenario in my mind where this would happen.. could be just
me this AM ;-)

R

> Do you have any comment on this?

-----
Randall Stewart
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 21 Apr 2013 15:29:40 -0700

Hello Randy,

What I meant was "in ideal equilibrium state", I mean a situation something
like where SCTP is in CA, cwnd is relatively large, self-clocking works
perfectly.
In this situation, while cwnd -1 packets are outstanding, you'll get one
ACK for 1 MSS from the receiver, then you'll send 1 packet. If I-bit is
enabled, I-bit will be set in the packet since it fills cwnd.
Then, you'll get one ACK for 1MSS due to I-bit and sender sends 1 packet
with I-bit and so on...
But, as I wrote before, I don't think this won't be a problem, I just would
like to clarify there might be a situation where I-bit is set in many
packets. Please point out if I miss something..

Thanks,
--
Yoshifumi