Re: SCTP mis indication counting during Fast Recovery

Hi Randy,

 

I am ok with this not being in RFC4960,

but I don’t really buy the argument about not knowing or the argument about the delays.

This is generally true for ALL mis-indication counts.

Let’s consider this discussion as closed, we/I will get what we/I want from RFC6675 additions to SCTP.

 

However, getting these arguments from you, then out of curiosity, I wonder if you have the time and

the strength to explain the motivation for the existing text of RFC4960 saying:

 

If an endpoint is in Fast Recovery and a SACK

arrives that advances the Cumulative TSN Ack Point, the

miss indications are incremented for all TSNs reported

missing in the SACK.

 

Thanks J

 

BR, Karen

 

 

 

From: Randall Stewart [mailto:rrs <at> netflix.com]
Sent: 23. oktober 2014 21:47
To: Karen Elisabeth Egede Nielsen
Cc: bidulock <at> openss7.org; Michael Tuexen; tsvwg <at> ietf.org
Subject: Re: [tsvwg] SCTP mis indication counting during Fast Recovery

 

Karen:

 

Assume the TSN’s (same sequence) are sent 100ms apart.. 

 

Sure we can construct a condition where they all go at once, but I can

also construct a condition where they do not. You can’t increment FR counts

on things you have not been told.

 

You *can* implement one of the alternative schemes that folks have been floating around

to recover from tail drops.. but that was never in the spec and won’t ever be in 4960.

It may be in some other RFC, thats fine, but 4960 never had the changes in it (however good

or bad they may be) you are asking for..

 

R

On Oct 23, 2014, at 12:35 PM, Karen Elisabeth Egede Nielsen <karen.nielsen <at> tieto.com> wrote:



Hi,

The TSN are sent at the same time, not sequentially.

Assume they chunks are  ~0,6*MTU, then there would be no CWND constrains and
no HB burst constraints.
This I am saying just to avoid to get into such discussions or bundling
discussions for that matter.

BR, Karen




-----Original Message-----
From: Brian F. G. Bidulock [mailto:bidulock <at> openss7.org]
Sent: 23. oktober 2014 21:12
To: Karen Elisabeth Egede Nielsen
Cc: Randall Stewart; Michael Tuexen; tsvwg <at> ietf.org
Subject: Re: [tsvwg] SCTP mis indication counting during Fast Recovery

Karen,

Please see comments inline:

On Thu, 23 Oct 2014, Karen Elisabeth Egede Nielsen wrote:


  HI,

  Let's assume SCTP send a batch of packets, the packets marked with L
  below are dropped, the packets with S are sacked.

  There is no more new data to send.

  SACKs arrive resulting in the following scorebard:

  LSSSLL

  in order from low -  high TSN.

  This makes SCTP fast retransmit the first lost packet setting FR exit
  point to last TSN.

  resulting in increase of cumack and following scoreboard (A indicate
  cumack'ed) once this TSN is sacked (which I assume).

  AAAALL

  There is 0 miscounts of the last two lost packets even if one packet
  send since them obviously have been Sacked.


TSN 1 ----------------> X
TSN 2 ----------------------------->
      <----------------------------- SACK 0, 2-2  TSN 1 peg = 1  TSN
3 -------------------
---------->
      <----------------------------- SACK 0, 2-3  TSN 1 peg = 2  TSN
4 -------------------
---------->
      <----------------------------- SACK 0, 2-4  TSN 1 peg = 3  Enter FR
exit point =
TSN 1  TSN 1 ----------------------------->
      <----------------------------- SACK 4  CA TSN >= exit point => exit
FR  TSN 5 ---
-------------> X  TSN 6 ----------------> X

At what point is the FR exit point greater than the highest  outstanding
TSN
in a SACK?  That is, at what point would pegging  up to the exit point
include
more TSNs that provided in the SACK?



  Assumed also the following loss pattern. no new packets:

  LSLSLSLL

  Then   again this makes SCTP fast retransmit the first lost packet
  setting FR exit point to last TSN.

  After SACK of the retransmitted packet we have:

  AALSLSLL and the first loss (TSN packet number 3) will now have 3
  miscounts and will be allowed to be fast retransmitted following the
  rule,

  the same again for the third L. But the ones lost in the end do not
get
  any miscounts even if they same rule that apply to the first Lost
  packets should

  apply to the last lost ones.


TSN 1 ----------------> X
TSN 2 ----------------------------->
      <----------------------------- SACK 0, 2-2  TSN 1 peg = 1  TSN
3 ---------------->
X  TSN 4 ----------------------------->
      <----------------------------- SACK 0, 2-2, 4-4  TSN 1 peg = 2, TSN
3 peg = 1
TSN 5 ----------------> X  TSN 6 ----------------------------->
      <----------------------------- SACK 0, 2-2, 4-4, 6-6  TSN 1 peg =
3, TSN 3 peg =
2, TSN 5 peg = 1  Enter FR  exit point = TSN 5  TSN
1 ----------------------------->
      <----------------------------- SACK 2, 4-4, 6-6  TSN 3 peg = 3, TSN
5 peg = 2
TSN 3 ----------------------------->
      <----------------------------- SACK 4, 6-6  TSN 5 peg = 3  TSN
5 -------------------
---------->
      <----------------------------- SACK 6  CA TSN >= exit point => exit
FR  TSN 7 ---
-------------> X  TSN 8 ----------------> X

At what point is the FR exit point greater than the highest  outstanding
TSN
in a SACK?  That is, at what point would pegging  up to the exit point
include
more TSNs that provided in the SACK?



  I have written this a little hastely. I hope this can give the
picture.

  Perhaps with this explanation also the information in slide 30-33 of
  the following now makes sense:


[1]http://www.ietf.org/proceedings/90/slides/slides-90-tsvwg-16.pdf,

  BR, Karen

  From: Randall Stewart [mailto:[2]rrs <at> netflix.com]
  Sent: 23. oktober 2014 16:48
  To: Karen Elisabeth Egede Nielsen
  Cc: Michael Tuexen; [3]bidulock <at> openss7.org
  Subject: Re: [tsvwg] SCTP mis indication counting during Fast
Recovery

  Karen:

  Note I dropped tsvwg due to the fact that this email would get locked
  up and held/bounced since [4]rrs <at> netflix.com is
  not a subscriber to tsvwg

  I like Brian am a bit confused by your request in that I don't see
how
  this could happen.

  SCTP has the ability to identify 300+ sack gaps. I think this
  is why the wording is the way it is. We could not conceive of a
situation
  where the SACK would come back (outside of reneging) and not list
what
  was previously there. Especially if the SACK is a response to the
  fast-retransmit.

  In theory it *should* contain all the gap acks that were present up
to
  your "fast recovery point".

  Like Brian I too don't remember ever making a "fast recovery point"
in
  SCTP.

  Now I guess you could get a situation where the fast retransmit
passed

the

  last TSN sent and the sender is thus responding.. but thats still
  pending data that *may* still arrive.

  So unless the sender purposely stops gap-acking previously gap-acked
  packets (reneged) then I don't see how this could happen.

  Could you explain how you see this could happen .. it could be I am
  missing something that is clear to you..

  Thanks


--
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

 

--------

Randall Stewart

803-317-4952

 

 

 

 

Yoshifumi Nishida | 24 Oct 06:59 2014
Picon

Fwd: Comments on SCTP draft-ietf-tsvwg-sctp-failover-05

Hi Gorry,

Thanks for the detailed reviews (again!)
We've updated our draft based on your suggestions and submitted it as -07 draft. (Sorry, I've made a mistake in 06 and resubmitted 07)
We believe there's no discrepancy, but just in case, I've inserted some comments in lines.

Thank you so much!
--
Yoshi


On Fri, Oct 3, 2014 at 2:26 AM, <gorry <at> erg.abdn.ac.uk> wrote:
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-05

As a Chair, I think the above draft seems in good shape from a protocol
perspective, if people see other ways to improve the protocol - it would
be good to know at this stage.

The authors have requested that this be considered as a PS. I have
therefore given this a more critical read - especially carefully looking
at the language, and suggest they consider the comments below and re-issue
the draft.  If we are to consider the draft as PS, then  I think a section
needs to be added to motivate this change (which *WILL* be confirmed on
this list after this revision).

Comments follow on the document (with no intended change to thee
protocol), please consider these - I'd love to hear from others on the
list if they also have any comments on this version!

Gorry
(tsvwg chair)




Section 4: (NiT in language)

/In order to address the issues described in Section 3, We propose to
   update SCTP path management scheme as follows./
to
/To address the issues described in Section 3, this section
   updates SCTP path management:/
-If this is to be considered as a PS, it /specifies/ the update.

Section 4.1: (language, there is no ordering so avoid this usage):
/In order to minimize performance impact during failover/
to
/To minimise the performance impact during failover/

Done.
 

Section 4.1 (structure)

- If I understand correctly, the first two paras, including the 2 bullets
are actually informative discussion to introduce the method, if this is
the case could these be moved to section 4, so thats action 4.1 includes
the RFC2119 protocol update.

We've split Section 4.1 into two sections: "concept" and "algorithm detail". Section 4.2 includes 2119 update.
We've also changed the title of Section 4.3 to clarify this is an optional feature.
 

Section 4.1: (NiT in language)
/tweaking/tuning/

/This proposal introduces/This new method introduces/

Done. 


Requirement  1 (RFC2119)
/The recommended value of PFMR = 0  when quick failover is used.  /
- is this /RECOMMENDED/ ?

We've changed to RECOMMENDED.
 

Requirement 3: (NiT in language)
/PF state with least error count/
/PF state with the lowest error count/

/In case of multiple PF/
/When there are multiple PF/

Done.
 

Requirement 4: (Clarity) 

/This
        specification recommends that heartbeats be send to PF
        destinations independently from whether the Path Heartbeat
        function (Section 8.3 of [RFC4960]) is enabled for the
        destination address or not./
- This appears at the end of the requirement. I'm not sure what is
intended, could it be that this
RECOMMENDS the use of heartbeats with PF, in which case I'd have expected
this requirement perhaps to be stated first?

We've changed the sentence to:

        It is RECOMMENDED that heartbeats be send to PF destinations
        regardless of whether the Path Heartbeat function
        (Section 8.3 of [RFC4960]) is enabled for the destination
        address or not.

Since this is not strong requirement, I think it doesn't have to be stated first.
 

Requirement 7: (NiT in language)

/state with least error count/
/state with the lowest error count/

/In  case of multiple destinations with same error count in inactive
        state/
/When there are multiple destinations with the same error count in the
inactive state/

Done. 

Requirement 4: (RFC2119)


/In order to support this
        prescription a sender SHOULD allow for increment of the
        destination error counters up to some reasonable limit above
        PMR+1/
/Therefore, a sender SHOULD allow for incrementing the
        destination error counters up to some reasonable limit above
        PMR+1/
- I can see the goal of reasonable limit, but is this actually a "limit"
- that stops further incrementing or "permits" the value to be incremented
beyond PMR+1?

Done. We've changed this to:

Therefore, a sender SHOULD allow for incrementing the
destination error counters up to some reasonable limit larger than PMR+1.
 

/A  sender MAY choose to deploy other strategies than the above/
- good to state this, but this is the second part of a SHOULD statement
explaining options, as such I do not think it needs an upper case /MAY/
and suspect that /may/ will be sufficient.

Agree. changed to may.
 

Requirement 8: (NiT in language)

/ACKs for chunks which have been transmitted to multiple
        destinations (i.e., a chunk which has been retransmitted to a
        different destination than the destination to which the chunk
        was first transmitted) /
/ACKs for chunks that have been transmitted to multiple
        destinations (i.e., a chunk that has been retransmitted to a
        different destination than the destination to which the chunk
        was first transmitted) /
- change /which/ to /that/

Use upper case for /ack/?

Done. 

/In this respect then it is specified
        that bytes of a newly acknowledged chunk which has been
        transmitted to multiple destinations SHOULD, when the conditions
        for such contribution is fulfilled following the prescriptions
        of Section 7.2 of [RFC4960], contribute to the congestion window
        growth towards the destination to which the chunk was last
        transmitted. /
- This clause is rather complex and long, please rephrase!


We've changed it to:
     The bytes of a newly acknowledged chunk which has been transmitted                                                    
     to multiple destinations SHOULD be considered for contribution to                                                     
     the congestion window growth towards the destination where the chunk was last sent.                                   
     The contribution of the acked bytes to the window growth is subject to                                                
     the prescriptions described in Section 7.2 of [RFC4960] is fulfilled.        
 

/A SCTP sender MAY apply a different approach for
        both the error count handling as well as the congestion control
        growth handling does it have unequivocally information as to
        which destination (including multiple destinations) the chunk
        reached.  /

- This clause is rather complex, and hard to parse, please rephrase!


We've changed this to:

        A SCTP sender MAY apply a different approach for
        both the error count handling and the congestion control growth
        handling based on unequivocally information on which destination
        (including multiple destinations) the chunk reached. 



Requirement 10: (Clarity)

/SCTP SHOULD provide the means to expose the PF state /
- Is this the SCTP stack should expose to the ULP, please clarify, and use
language similar to other SCTP RFCs.

/Active state ./ - remove space before stop,


/When  doing such SCTP MUST /
/When  this, the SCTP stack MUST /

/suppress exposure of PF state to ULP.  /
/suppress exposure of PF state to the ULP.  /

Done.
 

- I found this requirement not so clearly explained, and rather hard to
comprehend from the text.

We've changed this to:

            SCTP stack SHOULD provide the ULP with the means to expose the PF state of its                                    
            destinations as well as the means to notify the state transitions from Active to PF and vice-versa.                  
            When doing this, such SCTP stack MUST provide the ULP with the means to suppress exposure of PF                       
            state and association state transitions as well.  
 

Section 4.2: (RFC2119, Clarity)

/Post failover then, by [RFC4960] behavior, an SCTP sender migrates
   the traffic back to the original primary destination once this
   destination becomes active anew.  /
- This doesn’t seem to make sense.


We've changed this to:

   In [RFC4960], an SCTP sender migrates the traffic back to the
   original primary destination once this destination becomes active
   again.  


No 1

/Any setting of PSMR < PFMR
       MUST be rejected by the implementation./
- MUST be rejected seems odd. Can you phrase this the other way around?
The PSMR MUST be set so that PSMAR>=PFMR.
- This seems to contradict the previous SHOULD.

We've changed this to:
            The PSMR MUST be set greater or equal to the PFMR value.                                                                                   
            Implementations MUST reject any other values of PSMR.
 

No 2 and 3 do not introduce RFC 2119 requirements. Is this intentional, if
so why?

No 4
/support set of PSMR = PFMR/
/support the setting of PSMR = PFMR/


/ We recommend that SCTP-PF sticks to the standard RFC4960 switchback
   behavior as default/
- is this intended to be:
/This specifications RECOMMENDS a default configuration that uses standard
RFC4960 switchback./

/However in order to support//However, to support/

done 

- does this section need the MAYs in capital letters, since it follows a
SHOULD?

Yes. changed to MAY
 



Section 6:

I’m happy with this clause, if it is correct. For clarity I’d prefer the
section is prefixed by something like:
“Secutity considerations for the use of SCTP are discussed in RFCxxx and
RFCyyyy.”

Yes. We've added the sentences in the section.
 
Appendices: (Structure)

Two appendices are provided, but seem not to be described in the body of
the specification. - please either add references were appropriate to the
appendices or remove them.

We've add some texts to refer them at the end of Section 1.
 

Proposed change of status

I would expect such a section to b marked for removal before publication
by RFC-Ed (since this is ONLY an AD/IESG decision - that provides a couple
of short paras that document the evolution of the draft from EXP to PS,
and motivate that the experimental considerations are no longer an issue.
I believe the authors have clearly put this argument in the past, and hope
that this is not a difficult section to add.

We've added Section 8 for this.


Brian F. G. Bidulock | 23 Oct 21:12 2014

Re: SCTP mis indication counting during Fast Recovery

Karen,

Please see comments inline:

On Thu, 23 Oct 2014, Karen Elisabeth Egede Nielsen wrote:

>    HI,
> 
>    Let's assume SCTP send a batch of packets, the packets marked with L
>    below are dropped, the packets with S are sacked.
> 
>    There is no more new data to send.
> 
>    SACKs arrive resulting in the following scorebard:
> 
>    LSSSLL
> 
>    in order from low -  high TSN.
> 
>    This makes SCTP fast retransmit the first lost packet setting FR exit
>    point to last TSN.
> 
>    resulting in increase of cumack and following scoreboard (A indicate
>    cumack'ed) once this TSN is sacked (which I assume).
> 
>    AAAALL
> 
>    There is 0 miscounts of the last two lost packets even if one packet
>    send since them obviously have been Sacked.

 TSN 1 ----------------> X
 TSN 2 ----------------------------->
       <----------------------------- SACK 0, 2-2
 TSN 1 peg = 1
 TSN 3 ----------------------------->
       <----------------------------- SACK 0, 2-3
 TSN 1 peg = 2
 TSN 4 ----------------------------->
       <----------------------------- SACK 0, 2-4
 TSN 1 peg = 3
 Enter FR  exit point = TSN 1
 TSN 1 ----------------------------->
       <----------------------------- SACK 4
 CA TSN >= exit point => exit FR
 TSN 5 ----------------> X
 TSN 6 ----------------> X

 At what point is the FR exit point greater than the highest
 outstanding TSN in a SACK?  That is, at what point would pegging
 up to the exit point include more TSNs that provided in the SACK?

>    Assumed also the following loss pattern. no new packets:
> 
>    LSLSLSLL
> 
>    Then  again this makes SCTP fast retransmit the first lost packet
>    setting FR exit point to last TSN.
> 
>    After SACK of the retransmitted packet we have:
> 
>    AALSLSLL and the first loss (TSN packet number 3) will now have 3
>    miscounts and will be allowed to be fast retransmitted following the
>    rule,
> 
>    the same again for the third L. But the ones lost in the end do not get
>    any miscounts even if they same rule that apply to the first Lost
>    packets should
> 
>    apply to the last lost ones.

 TSN 1 ----------------> X
 TSN 2 ----------------------------->
       <----------------------------- SACK 0, 2-2
 TSN 1 peg = 1
 TSN 3 ----------------> X
 TSN 4 ----------------------------->
       <----------------------------- SACK 0, 2-2, 4-4
 TSN 1 peg = 2, TSN 3 peg = 1
 TSN 5 ----------------> X
 TSN 6 ----------------------------->
       <----------------------------- SACK 0, 2-2, 4-4, 6-6
 TSN 1 peg = 3, TSN 3 peg = 2, TSN 5 peg = 1
 Enter FR  exit point = TSN 5
 TSN 1 ----------------------------->
       <----------------------------- SACK 2, 4-4, 6-6
 TSN 3 peg = 3, TSN 5 peg = 2
 TSN 3 ----------------------------->
       <----------------------------- SACK 4, 6-6
 TSN 5 peg = 3
 TSN 5 ----------------------------->
       <----------------------------- SACK 6
 CA TSN >= exit point => exit FR
 TSN 7 ----------------> X
 TSN 8 ----------------> X

 At what point is the FR exit point greater than the highest
 outstanding TSN in a SACK?  That is, at what point would pegging
 up to the exit point include more TSNs that provided in the SACK?

>    I have written this a little hastely. I hope this can give the picture.
> 
>    Perhaps with this explanation also the information in slide 30-33 of
>    the following now makes sense:
> 
>    [1]http://www.ietf.org/proceedings/90/slides/slides-90-tsvwg-16.pdf,
> 
>    BR, Karen
> 
>    From: Randall Stewart [mailto:[2]rrs <at> netflix.com]
>    Sent: 23. oktober 2014 16:48
>    To: Karen Elisabeth Egede Nielsen
>    Cc: Michael Tuexen; [3]bidulock <at> openss7.org
>    Subject: Re: [tsvwg] SCTP mis indication counting during Fast Recovery
> 
>    Karen:
> 
>    Note I dropped tsvwg due to the fact that this email would get locked
>    up and held/bounced since [4]rrs <at> netflix.com is
>    not a subscriber to tsvwg
> 
>    I like Brian am a bit confused by your request in that I don't see how
>    this could happen.
> 
>    SCTP has the ability to identify 300+ sack gaps. I think this
>    is why the wording is the way it is. We could not conceive of a situation
>    where the SACK would come back (outside of reneging) and not list what
>    was previously there. Especially if the SACK is a response to the
>    fast-retransmit.
> 
>    In theory it *should* contain all the gap acks that were present up to
>    your "fast recovery point".
> 
>    Like Brian I too don't remember ever making a "fast recovery point" in
>    SCTP.
> 
>    Now I guess you could get a situation where the fast retransmit passed the
>    last TSN sent and the sender is thus responding.. but thats still
>    pending data that *may* still arrive.
> 
>    So unless the sender purposely stops gap-acking previously gap-acked
>    packets (reneged) then I don't see how this could happen.
> 
>    Could you explain how you see this could happen .. it could be I am
>    missing something that is clear to you..
> 
>    Thanks
> 

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Brian F. G. Bidulock | 23 Oct 15:07 2014

General comments on slides-90-tsvwg-16.pdf

Karen,

In your presentation,

  http://www.ietf.org/proceedings/90/slides/slides-90-tsvwg-16.pdf

you asked for comments on tsvwg on the material presented.  Here are
some general comments.

The procedures described appear to be concerned with avoiding T3
timeouts in as many scenarios as possible.  Stepping back and
thinking about that, I wonder what can be achieved by completely
eclipsing the T3 timeout procedure.  The procedures appear to
proceed from the assumption that T3 timeouts are evil and to be
avoided at all cost.

The evil appears to pivot on increased latencies in lossy network
(whether due to congestion or transmission errors) and not so much
on congestion avoidance procedures (cwnd).  The statement of evil,
if you will, appears to be: It takes a longer time for a T3 timeout
to occur than is necessary because better information about loss
can be available before the timeout ensues.

What RTO_MIN value are you using in your experiments?  For SIGTRAN
we have been using a RTO_MIN value of zero (0) for quite some time.
For example, ETSI TS 102 144 V1.1.1 (2003-05) specified the minimum
value for RTO.Min as 10 ms and specified with a granularity of 10 ms.
(Note that the common clock tick at the time was 10ms.)  This was
also mentioned in RFC4166/3.2.1.

There are a couple of well-known procedures that can be used to
mitigate spurious retransmissions when using a low RTO.min:

 - setting SACK_DELAY to zero (0) on both sides, or not penalizing
   a receiver for having a SACK_DELAY > RTO.

 - initiating an immediate HB probe for a destination when RTO
   approaches the granularity of the system clock to quickly
   recover a destination (especially when PMR is set to 0 or 1).

An extremely high RTO.min (e.g. 1 second) will make any procedure
that avoids a T3 timeout look good on the surface.

If your implementation is capable of setting RTO.min to zero, you
could try rerunning your experiments with an RTO.min of zero (0) to
determine whether falling back on T3 timeout is such a bad thing
after all.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

SCTP mis indication counting during Fast Recovery

 Hi,

 

I have come to realize that I for the SCTP TLP (SCTP Tail Loss probe additions) and SCTP FR improvements (adoptation of certain RFC6675 nextseg() features for SCTP FR) that we are working on (as presented at IETF 90) have made an assumption on the SCTP FR function which is neither aligned with our

actual SCTP implementation nor with the text of RFC4960 (/RFC4460) as written (section 7.2.4).

 

However in order to better understand the motivation for the text of RFC4960 as written,

I would appreciate very much if the wg would comment on the following formulation of RFC4960 section 7.2.4:

 

If an endpoint is in Fast Recovery and a SACK

   arrives that advances the Cumulative TSN Ack Point, the

   miss indications are incremented for all TSNs reported

   missing in the SACK.

 

Especially on why the text DOES NOT read:

 

If an endpoint is in Fast Recovery and a SACK

   arrives that advances the Cumulative TSN Ack Point, the

   miss indications are incremented for all TSNs still

   missing up to and including the Fast Recovery Exit Point.

 

 

The basic philosophi being that when the cum ack advances, then the newly cum ack’ed TSN has

been assumed lost, has been retransmitted and consequently the mis indication count should go up for

all still missing TSNs up to and including the Fast Recovery Exit Point.

 

It is clear that the above aproach by no means is bullet proof in the sense that it may very well be that the cum ack advances

due to receipt of SACK without this in fact being a result of the receipt by peer of a fast retransmitted TSN, but this is the situation

also with the approach written into RFC4960.

 

Many thanks in advance.

 

BR, Karen

 

 

 

SCTP ndata SCTP-PR priority

Hi Michael,

 

I think that it could be beneficiary in the ndata draft to relate to (describe) how the ndata SS-PRIORITY scheduling may be used together

with the SCTP-PR priority policy to support “accelerated” prioritized delivery in which the priority messages will not only be able to expel lower priority data from the SND buffer but, also be able to outrace lower priority messages (set to be send on lower priority streams) from  a transmission perspective.

 

Apart from the relevance from a usecase perspective then I think that such a description could be relevant also in order to emphasize the difference

in between the message priority of SCTP-PR and the stream priority of ndata.  For example I think that it is particularly be relevant to state explicitly that the priority given to stream does not carry over to (has no relation to) the SCTP-PR message priority or the messages send on the stream.

 

Alternatively – juts for the sort of it - but this I think would be an addition to/a change of SCTP-PR, RFC6458 and ndata-draft – then one could also look to that the default SCTP-PR message priority be inherited from the stream priority SS-PRIORITY or one may ask for a special version of the stream scheduling SS_PRIORITY* in which this be the case. This would alleviate SCTP Users from having to pass also the prinfo down in case the priority in wished managed simply by differentiation on streams. The stream priority has advantages from a receive perspective in that it would be feasible to  implement priority on a stream perspective on the reading side. This is not feasible for the per message prioritization.

 

Thanks.

 

BR, Karen

 

 

 

*****************************************************************************************

Karen Egede Nielsen

Software Architect, Ph.D.

 

Tieto Denmark A/S

R&D, Telecom & Media

Åhave Parkvej 27, 8260 Viby J, DK-Denmark

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen <at> tieto.com

*****************************************************************************************

www.tieto.com 

 

Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.

 

 

 

 

 

Gorry Fairhurst | 14 Oct 09:51 2014
Picon
Picon

WGLC draft-ietf-tsvwg-port-use-05 : Working Group Last Call for comments due 29/10/2014

This email announces the start of a working group last call to
confirm publication of draft-ietf-tsvwg-port-use,
"Recommendations for Transport Port Number Uses".  This document has
received significant feedback during the first WGLC review and has now 
been updated in response to this feedback. It is now thought to be ready 
to proceed to be published as a BCP.

Please send any comments to the TSVWG list. We are interesed in feedback 
from any who have read the latest version, including those who commented 
in the first WGLC.

The draft is available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-port-use-05

This last call will run for TWO weeks, ending 29th October.

James, David, and Gorry
(TSVWG Chairs)
tsvwg-chairs <at> ietf.org

Weixinpeng | 8 Oct 09:14 2014

FW: New Version Notification for draft-wei-tsvwg-tunnel-congestion-feedback-03.txt

Hi all,
A new version of network based congestion control draft has been submitted.

In the last Toronto meeting, we presented our simulation result about the impacts of network based
congestion control on end-to-end congestion control and the result seems acceptable to the people.

In this new version, several small issues that people may be interested in are clarified, including what
information would be conveyed from tunnel egress to ingress for congestion control, how tunnel ingress
could use the information to reduce congestion level in tunnel.

So now we want to know whether you have any comments or suggestions for this? 

Best Regards,
Xinpeng

>-----Original Message-----
>From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
>Sent: Wednesday, October 08, 2014 12:04 PM
>To: Weixinpeng; Lingli Deng; Zhulei (MBB Research); Zhulei (MBB Research);
>Weixinpeng; Lingli Deng
>Subject: New Version Notification for
>draft-wei-tsvwg-tunnel-congestion-feedback-03.txt
>
>
>A new version of I-D, draft-wei-tsvwg-tunnel-congestion-feedback-03.txt
>has been successfully submitted by Xinpeng Wei and posted to the IETF
>repository.
>
>Name:		draft-wei-tsvwg-tunnel-congestion-feedback
>Revision:	03
>Title:		Tunnel Congestion Feedback
>Document date:	2014-10-08
>Group:		Individual Submission
>Pages:		20
>URL:
>http://www.ietf.org/internet-drafts/draft-wei-tsvwg-tunnel-congestion-feedb

>ack-03.txt
>Status:
>https://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-congestion-feedback/

>Htmlized:
>http://tools.ietf.org/html/draft-wei-tsvwg-tunnel-congestion-feedback-03

>Diff:
>http://www.ietf.org/rfcdiff?url2=draft-wei-tsvwg-tunnel-congestion-feedback-

>03
>
>Abstract:
>   This document describes a mechanism to calculate congestion of a
>   tunnel segment based on RFC 6040 recommendations, and a feedback
>   protocol by which to send the measured congestion of the tunnel from
>   egress to ingress router. A basic  model for measuring tunnel
>   congestion and feedback is described, and a protocol for carrying the
>   feedback data is outlined.
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

gorry | 3 Oct 11:26 2014
Picon
Picon

Comments on SCTP draft-ietf-tsvwg-sctp-failover-05

https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-05

As a Chair, I think the above draft seems in good shape from a protocol
perspective, if people see other ways to improve the protocol - it would
be good to know at this stage.

The authors have requested that this be considered as a PS. I have
therefore given this a more critical read - especially carefully looking
at the language, and suggest they consider the comments below and re-issue
the draft.  If we are to consider the draft as PS, then  I think a section
needs to be added to motivate this change (which *WILL* be confirmed on
this list after this revision).

Comments follow on the document (with no intended change to thee
protocol), please consider these - I'd love to hear from others on the
list if they also have any comments on this version!

Gorry
(tsvwg chair)

—

Section 4: (NiT in language)

/In order to address the issues described in Section 3, We propose to
   update SCTP path management scheme as follows./
to
/To address the issues described in Section 3, this section
   updates SCTP path management:/
-If this is to be considered as a PS, it /specifies/ the update.

Section 4.1: (language, there is no ordering so avoid this usage):
/In order to minimize performance impact during failover/
to
/To minimise the performance impact during failover/

Section 4.1 (structure)

- If I understand correctly, the first two paras, including the 2 bullets
are actually informative discussion to introduce the method, if this is
the case could these be moved to section 4, so thats action 4.1 includes
the RFC2119 protocol update.

Section 4.1: (NiT in language)
/tweaking/tuning/

/This proposal introduces/This new method introduces/

Requirement  1 (RFC2119)
/The recommended value of PFMR = 0  when quick failover is used.  /
- is this /RECOMMENDED/ ?

Requirement 3: (NiT in language)
/PF state with least error count/
/PF state with the lowest error count/

/In case of multiple PF/
/When there are multiple PF/

Requirement 4: (Clarity)

/This
        specification recommends that heartbeats be send to PF
        destinations independently from whether the Path Heartbeat
        function (Section 8.3 of [RFC4960]) is enabled for the
        destination address or not./
- This appears at the end of the requirement. I'm not sure what is
intended, could it be that this
RECOMMENDS the use of heartbeats with PF, in which case I'd have expected
this requirement perhaps to be stated first?

Requirement 7: (NiT in language)

/state with least error count/
/state with the lowest error count/

/In  case of multiple destinations with same error count in inactive
        state/
/When there are multiple destinations with the same error count in the
inactive state/

Requirement 4: (RFC2119)

/In order to support this
        prescription a sender SHOULD allow for increment of the
        destination error counters up to some reasonable limit above
        PMR+1/
/Therefore, a sender SHOULD allow for incrementing the
        destination error counters up to some reasonable limit above
        PMR+1/
- I can see the goal of reasonable limit, but is this actually a "limit" 
- that stops further incrementing or "permits" the value to be incremented
beyond PMR+1?

/A  sender MAY choose to deploy other strategies than the above/
- good to state this, but this is the second part of a SHOULD statement
explaining options, as such I do not think it needs an upper case /MAY/
and suspect that /may/ will be sufficient.

Requirement 8: (NiT in language)

/ACKs for chunks which have been transmitted to multiple
        destinations (i.e., a chunk which has been retransmitted to a
        different destination than the destination to which the chunk
        was first transmitted) /
/ACKs for chunks that have been transmitted to multiple
        destinations (i.e., a chunk that has been retransmitted to a
        different destination than the destination to which the chunk
        was first transmitted) /
- change /which/ to /that/

Use upper case for /ack/?

/In this respect then it is specified
        that bytes of a newly acknowledged chunk which has been
        transmitted to multiple destinations SHOULD, when the conditions
        for such contribution is fulfilled following the prescriptions
        of Section 7.2 of [RFC4960], contribute to the congestion window
        growth towards the destination to which the chunk was last
        transmitted. /
- This clause is rather complex and long, please rephrase!

/A SCTP sender MAY apply a different approach for
        both the error count handling as well as the congestion control
        growth handling does it have unequivocally information as to
        which destination (including multiple destinations) the chunk
        reached.  /

- This clause is rather complex, and hard to parse, please rephrase!

Requirement 10: (Clarity)

/SCTP SHOULD provide the means to expose the PF state /
- Is this the SCTP stack should expose to the ULP, please clarify, and use
language similar to other SCTP RFCs.

/Active state ./ - remove space before stop,

/When  doing such SCTP MUST /
/When  this, the SCTP stack MUST /

/suppress exposure of PF state to ULP.  /
/suppress exposure of PF state to the ULP.  /

- I found this requirement not so clearly explained, and rather hard to
comprehend from the text.

Section 4.2: (RFC2119, Clarity)

/Post failover then, by [RFC4960] behavior, an SCTP sender migrates
   the traffic back to the original primary destination once this
   destination becomes active anew.  /
- This doesn’t seem to make sense.

No 1

/Any setting of PSMR < PFMR
       MUST be rejected by the implementation./
- MUST be rejected seems odd. Can you phrase this the other way around?
The PSMR MUST be set so that PSMAR>=PFMR.
- This seems to contradict the previous SHOULD.

No 2 and 3 do not introduce RFC 2119 requirements. Is this intentional, if
so why?

No 4
/support set of PSMR = PFMR/
/support the setting of PSMR = PFMR/

/ We recommend that SCTP-PF sticks to the standard RFC4960 switchback
   behavior as default/
- is this intended to be:
/This specifications RECOMMENDS a default configuration that uses standard
RFC4960 switchback./

/However in order to support//However, to support/

- does this section need the MAYs in capital letters, since it follows a
SHOULD?

—

Section 6:

I’m happy with this clause, if it is correct. For clarity I’d prefer the
section is prefixed by something like:
“Secutity considerations for the use of SCTP are discussed in RFCxxx and
RFCyyyy.”

Appendices: (Structure)

Two appendices are provided, but seem not to be described in the body of
the specification. - please either add references were appropriate to the
appendices or remove them.

Proposed change of status

I would expect such a section to b marked for removal before publication
by RFC-Ed (since this is ONLY an AD/IESG decision - that provides a couple
of short paras that document the evolution of the draft from EXP to PS,
and motivate that the experimental considerations are no longer an issue.
I believe the authors have clearly put this argument in the past, and hope
that this is not a difficult section to add.

gorry | 28 Sep 21:23 2014
Picon
Picon

WGLC conclusion for draft-ietf-tsvwg-sctp-prpolicies

The above draft completed WGLC with minor comments, and resulted in a new
revision that just been published. If you commented during the WGLC,
please check that this revision resolves your issues, or send a message to
the tsvwg list.

If there are no new comments, the chairs plan to submit this to our AD
with the intended status of PS (including an INFO section describing the
socket API).

Best wishes,

Gorry
(tsvwg co-chair)

internet-drafts | 28 Sep 19:47 2014
Picon

I-D Action: draft-ietf-tsvwg-sctp-prpolicies-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol
        Authors         : Michael Tuexen
                          Robin Seggelmann
                          Randall R. Stewart
                          Salvatore Loreto
	Filename        : draft-ietf-tsvwg-sctp-prpolicies-04.txt
	Pages           : 10
	Date            : 2014-09-28

Abstract:
   This document defines two additional policies for the Partial
   Reliability Extension of the Stream Control Transmission Protocol
   (PR-SCTP) allowing to limit the number of retransmissions or to
   prioritize user messages for more efficient send buffer usage.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-prpolicies-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


Gmane