Request to publish: draft-ietf-tsvwg-source-quench as a PS.

This email includes a write-up of the IETF TSV WG document on 
"Deprecation of ICMP Source Quench messages".  This write-up will be 
forwarded to our ADs with a recommendation for publication as an RFC. 
Thanks to all who contributed to this work.

Best wishes,

Gorry (TSVWG Co-Chair)

---

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

Document: Deprecation of ICMP Source Quench messages 
<draft-ietf-tsvwg-source-quench-03.txt>
Intended status: Proposed Standards
Shepherd: G Fairhurst (TSVWG Co-Chair)

This version is dated September 17, 2008.

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

I (Gorry Fairgurst) will be the document shepherd and I judge that
this document is ready for publication.

Re: Fast Retransmission in SCTP

Re: Fast Retransmission in SCTP

Maxim:

Being one of the authors of the paper and research and having
done a few other things on SCTP.. I will add my 2 cents … mostly 
in-line .. but out of line here too 

In general sending FR to where they originally were sent is a good
idea. The reason being is the ACK clock is not broken.. you just noticed
something was lost. Once you move it to another destination you are moving
it to somewhere that is what the first Michael below describes…  and 
further more, if you do that, you can *not* do more than one fast retransmit
per packet. So if you have an unlucky packet that gets dropped twice but you
have not loss the ack-clock, you are going to take a full scale time-out in
order to get it through.

I have seen this happen in real networks and have found it best then to
keep the packet on the path it was originally sent on in general.

Now all of that is in *general true* for when
a) You have NOT switched primary's
<and>
b) You still have an ACK-Clock.

If on the other hand, the user has switched primary's or the primary has
died and move to another path. You may not wish to follow that advice.

The RFC very specifically left loose not adding any MUST so that an implementation
can have some freedom if it wants to worry about these corner cases. This is a good
thing.. since there are several corner cases that one can dream up that then the
standard advice.. keep the packet on the same path originally sent on.. would *not*
be a good choice.  

On Jan 17, 2012, at 5:11 AM, Maxim Proshin wrote:

> Hi,
> 
> it seems that your point is reasonable but it still requires some clarfifications:
> 
> 1. You are talking about "current primary path failovers". What if the user defined a destination? Should
SCTP send fast retransmissions to the primary destination anyway?

I personally would still hold the original path if the user swapped paths since the
ack clock will slowly shut down. Unless of course you know that there is nothing
left on that old path of course.. again this is quite a corner case. Most FR's will
happen with no switches, no deaths, just a momentary drop by a router in the network
to slow us down a bit.

> 
> 2. It is unclear how the Karns algorithm can affect RTO calculation during FR. If the primary destination
is just changed and gaps are detected for the previous primary destination, it means that RTO could not be
changed (at least due to Karns algorithm). Could you please clarify scenarious where it could happen? In
your item 1 you are talking about an alternative path and conservative RTO. I think you mean the previous
primary destination then it is unclear why its RTO is conservative.

> 
> 3. I agree with the drawback about CWND. But as usually there are pros and cons. How do you propose to
calculate CWND in this case? Should it be recalculated for the previous primary destination and new one
(or defined by the user and primary one)? Looks like it should be recalculated but in such case it impacts
SCTP performance and conflicts with RFC. It seems there are also problematic scenarious if CWND is
recalculated. What if the number of bytes in in-flight for the new primary destination is equal to CWND,
how fast retransmissions from the previous primary one should be made in such case, should it be
postponed? Moreover changing the primary destination is not normally done often and amount of fast
retransmissions to the previous primary destination will not give a big impact on CWND in comparison with
all data. 

I think this is again splitting hairs. The loss of one opportunity to grow the CWND in one
obscure corner case where the user switched primary's (or the path died) is not important.
If the user switches primary's he is going to take a hit anyway since the old path
with a very open cwnd (possibly) will of course have much more data going through it
vs the new path that is sitting at the initial window. In the case of path-death, well
again the new path will probably be in slow start and its just a consequence of the path
switch...

In fact actually the more I think on this it must be that the user switched the primary
since if the path exceeded its strike count and was marked as down, all the packets
in-flight or otherwise, must be moved to the new primary. 

Unless of course you get a double switch back, i.e. it restores.. in which case
we are again walking a very narrow corner. 

Again, this is why the wording is loose, to allow the implementations the ability to
add code to handle obscure corner cases if they wish.

R

> 
> BR, Maxim
> 
> 2011/12/21 Michael Vittrup Larsen <michael.larsen <at> tieto.com>
> I don't believe this is a correct interpretation of the articles from Armando
> et. al ([4] of RFC4460).  I believe the correct interpretation is
> 
>  "fast retransmissions should be sent to the destination to which
>   we currently are sending data"
> 
> Note that this is not the same as "...to the same destination where initial
> transmissions were sent" in case of current primary path failovers.  In fact,
> if we send fast retransmissions "...to the same destination where initial
> transmissions were sent" we may in fact be sending these on a path different
> from where we currently are sending data - and this is exactly (to my
> understanding) what the change in SCTP fast retransmission in RFC4960 is all
> about.
> 
> To see why we need to look behind the words used by RFC4960 and into the
> articles and the reasoning in the articles:
> 
> 1) Sending fast retransmissions (FR) on a path different from where we
> currently are sending new data may be subject to excessive RTO values on the
> alternative path. Successful FRs do not update the RTT of the alternative path
> due to Karns algorithm and the RTO on the alternative path is therefore
> conservative for the majority of the association and sending FRs on such a
> path is not optimal.
> 
> 2) FRs do not benefit the cwnd of the path where we are sending new data but
> instead the cwnd of the alternative path, which is less attractive.
> 
> 3) Possible timeouts of FRs sent on the alternative path will delay cwnd
> increments on the path where we are sending new data. Since these timeouts are
> conservative the delay may be excessive.
> 
> Neither [4] nor RFC4960 explicitly in text describes the FR policy in case
> where a change of the current primary data transfer path has occurred. But in
> essence the above reasoning/discovery of [4] clearly dictates what the correct
> interpretation should be.
> 
> 
> Regards,
> Michael
> 
> On Friday, December 09, 2011 11:34:34 Michael Tüxen wrote:
> > On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote:
> > > Hi experts,
> > >
> > > here I would like to discuss the Fast Retransmission algorithm in RFC
> > > 4960. Frankly this RFC does not describe clearly how to send (to which
> > > destination) fast retransmissions but we can find some information in
> > > RFC 4460 which says:
> > >
> > > "
> > > 2.39. Retransmission Policy
> > >
> > > 2.39.1. Description of the Problem
> > >
> > > The current retransmission policy (send all retransmissions an
> > > alternate destination) in the specification has performance issues
> > > under certain loss conditions with multihomed endpoints. Instead,
> > > fast retransmissions should be sent to the same destination, and only
> > > timeout retransmissions should be sent to an alternate destination [4].
> > > "
> > >
> > > Reading this article my first feeling was that fast retransmissions
> > > should be sent to the same destination where initial transmissions were
> > > sent.
> > >
> > > So my first question is
> > >
> > >  is my RFC interpretation correct or not?
> >
> > Yes. Fast retransmissions should be send to the same destination as the
> > initial transmission. Timer based retransmissions should use an alternate
> > destination.
> >
> > > Meanwhile, there are some more articles about retransmision policies
> > > where RFC's authors also participated. For instance, "Retransmission
> > > Policies With Transport Layer Multihoming" describes some improvements
> > > in fast retransmission policy in respect to RFC 2960 and I think that
> > > they were considered during RFC 4960 preparation. This analysis also
> > > proposes to send fast retransmissions to the same destination: "
> > > In this solution, all retransmissions are sent to the
> > > same destination as their original transmissions.
> > > ...
> > > Instead of all
> > > retransmissions following the Retransmit to Same Destination
> > > policy of Solution 1, only Fast Retransmissions
> > > should follow this policy.
> > > "
> > >
> > > It seems that this statement confirms my initial feeling described above.
> > > But at the same time it says about primary path: "
> > > Using the same destination for retransmissions has
> > > the added advantage that the primary destination's cwnd
> > > bene ts from successful retransmissions.
> > > "
> > > and it results is some doubts. On the one hand fast retransmissions
> > > should be sent to the same destination, on the other it should be sent
> > > to the primary destination. In usual case "the same" and primary
> > > destinations are equal. But RFC 4960 doesn't prevent primary destination
> > > changing by the user so it can be changed in run-time.
> > >
> > > So my second question is
> > >
> > >  if the primary destination is changed in run-time, where SCTP should
> > >  sent fast retransmissions which were detected for the previous primary
> > >  destination?
> >
> > Changing the primary is normally not done at a high rate. So you are
> > looking at the case where fast retransmission occur and the user changed
> > the primary in between.
> >
> > I guess there is no special case on the RFC for that. So the fast
> > retransmission would go to the destination to which it was initially sent.
> > The same applies if the user specified a destination and therefore the
> > primary was not used.
> >
> > > The mentioned above article describes one advantage in respect to sending
> > > to the primay destination, this is about cwnd benets from successful
> > > retransmission. But I think that in case of fast retransmission it will
> > > not be observed or the advantage is very very low.
> > >
> > > At the same time sending to the primary destination results in a big
> > > disadvantage: SCTP should recalculate cwnd if it sends fast
> > > retransmissions to the primary destination because RFC 4960 says: "
> > > When a Fast Retransmit is being performed, the sender SHOULD ignore the
> > > value of cwnd "
> > > I think the reason is that it was considered during initial transmission.
> >
> > If you do a fast retransmit, you assume that the packet has left the
> > network. So you would have to subtract and add it. This means ignoring...
> >
> > Best regards
> > Michael
> >
> > > What do you think about this?
> > >
> > > I'm not sure whether it was discussed already or not. If yes, please
> > > provide me with discussion's results.
> 
> --
> *****************************************************************************************
> Michael Vittrup Larsen
> Software Architect
> 
> Tieto Denmark A/S
> IP Solutions, Telecom & Media
> Skanderborgvej 232, 8260 Viby J, DK-Denmark
> Direct Phone / Mobile +45 3091 8469
> E-mail: michael.larsen <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.
> 
> 
> 
> -- 
> BR, Max

-----
Randall Stewart
randall <at> lakerest.net

AD review of draft-ietf-tsvwg-source-quench

I think there are two small process-oriented changes that need to be
made to this document prior to the IETF LC.

1 - I don't think it's proper to have a normative reference to RFC
    1016.  This would be a down-ref, and need to be called out that
    way in IETF LC, but I think the right thing to do is to not have
    it as normative in the first place, since not implementing a
    congestion response to SQ doesn't require 1016 (it un-requires
    it!).

2 - I think to make 1016 historic, we need "Obsoletes: 1016" in the
    header.

Otherwise, I think this is ready to go.

--

-- 
Wes Eddy
MTI Systems

Re: AD review of draft-ietf-tsvwg-source-quench

Hi, Wes,

On 01/19/2012 02:11 AM, Wesley Eddy wrote:
> I think there are two small process-oriented changes that need to be
> made to this document prior to the IETF LC.
> 
> 1 - I don't think it's proper to have a normative reference to RFC
>     1016.  This would be a down-ref, and need to be called out that
>     way in IETF LC, 

FWIW, my rationale for including it as "normative" was it wasn't just
"additional information" (i.e., informative), but since we were moving
it to historical, it was key to read it.

That aside, RFC 1016 is not assigned to any track, so in some sense it
was as including a normative ref to MD5 (which strictly speaking is a
down ref, but which we have done in the past).

>     but I think the right thing to do is to not have
>     it as normative in the first place, since not implementing a
>     congestion response to SQ doesn't require 1016 (it un-requires
>     it!).

No problem with that.

> 2 - I think to make 1016 historic, we need "Obsoletes: 1016" in the
>     header.

I seem to recall having an off-list discussion about this (with Alfred?)
but do not really recall the details. I tried looking up "the Obsoletes"
keyword in RFC 2026, but since its RFC-Editor metadata (?), it's not
even mentioned there.

That said, I agree with your suggestions. I will rev the I-D and post it
today, unless I hear anything against proceeding this way.

Thanks!

Best regards,
--

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: AD review of draft-ietf-tsvwg-source-quench

I think the obsoletes keyword will be essential and would support these
two edits. Go ahead Fernando!

Gorry

> Hi, Wes,
>
> On 01/19/2012 02:11 AM, Wesley Eddy wrote:
>> I think there are two small process-oriented changes that need to be
>> made to this document prior to the IETF LC.
>>
>> 1 - I don't think it's proper to have a normative reference to RFC
>>     1016.  This would be a down-ref, and need to be called out that
>>     way in IETF LC,
>
> FWIW, my rationale for including it as "normative" was it wasn't just
> "additional information" (i.e., informative), but since we were moving
> it to historical, it was key to read it.
>
> That aside, RFC 1016 is not assigned to any track, so in some sense it
> was as including a normative ref to MD5 (which strictly speaking is a
> down ref, but which we have done in the past).
>
>
>>     but I think the right thing to do is to not have
>>     it as normative in the first place, since not implementing a
>>     congestion response to SQ doesn't require 1016 (it un-requires
>>     it!).
>
> No problem with that.
>
>
>
>> 2 - I think to make 1016 historic, we need "Obsoletes: 1016" in the
>>     header.
>
> I seem to recall having an off-list discussion about this (with Alfred?)
> but do not really recall the details. I tried looking up "the Obsoletes"
> keyword in RFC 2026, but since its RFC-Editor metadata (?), it's not
> even mentioned there.
>
> That said, I agree with your suggestions. I will rev the I-D and post it
> today, unless I hear anything against proceeding this way.
>
> Thanks!
>
> Best regards,
> --
> Fernando Gont
> e-mail: fernando <at> gont.com.ar || fgont <at> si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>

I-D Action: draft-ietf-tsvwg-source-quench-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           : Deprecation of ICMP Source Quench messages
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-tsvwg-source-quench-04.txt
	Pages           : 9
	Date            : 2012-01-19

   This document formally deprecates the use of ICMP Source Quench
   messages by transport protocols, formally updating RFC 792, RFC 1122,
   and RFC 1812.  Additionally, it requests that the status of RFC 1016
   be changed to "Historic".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-04.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-04.txt

TSVWG Status Summary -- January 2012

The list below shows the status of the working group documents as we see 
it. Please check below and comment on drafts using the list. Please do 
send any corrections/omissions to the chairs.

Best wishes,

James and Gorry
(TSVWG Chairs)

---
Recently published:

draft-ietf-tsvwg-iana-ports was published as RFC 6335.
draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411.
draft-ietf-tsvwg-sctpsocket was published as RFC 6458.

IDs in RFC Editor Queue:

draft-ietf-tsvwg-sctp-strrst
   Dependency on this for IPFIX document with RFC-Ed.
   WGLC completed.
   James is Shepherd.

-------------------------------------------------------------------

IDs in IESG processing:

draft-ietf-tsvwg-source-quench
   (Replaced: draft-gont-tsvwg-source-quench-01.txt)
   IETF-79 suggested there was interest in this topic.
   Comments to list in 2010 from: Fred Baker, Antonio DeSimone,
   James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others.
   WG agreed the draft should be a work item.
   More motivation was needed to justify the SHOULD cases.
   WGLC completed.
   Gorry is Shepherd.
   Document write-up sent to WG (9th Jan 2012)
   Draft revised to add "obsoletes" line.
   DUE: AD review in progress

-------------------------------------------------------------------

WG Drafts with Chairs:

draft-ietf-tsvwg-byte-pkt-congest
   New editor added Jul 2010.
   New revision 25 Oct 2010.
   WG -01, June 10, 2011
   IETF-81: discussed whether this should be BCP.
   ADs & Chairs agree to progress as a BCP
   Status changed to BCP (new-ID WG -05)
   Presented at IEWTF-82 (Taipei), request for WGLC.
   Gorry added as Shepherd (Jan 2012)
   DUE: Reviewers need to volunteer for LC
   DUE: WG Chairs to review document with a view to WGLC
   Please comment on list.

-------------------------------------------------------------------

WG Drafts:

draft-ietf-tsvwg-natsupp-tsvwg
   (Replaced: draft-stewart-natsupp-tsvw)
   Dependency from BEHAVE WG.
   Adopted as a work item 21 Sept 2010 (Gorry).
   WG -00, 29/11/2010
   Uploaded as: draft-ietf-natsupp-tsvwg
   WG -01, June 1, 2011
   DUE: Reviews need.

draft-ietf-tsvwg-sctp-udp-encap
   (Replaced: draft-tuexen-sctp-udp-encap)
   Lars sent a note as AD agreeing to progress this work.
   Work to be coordinated with DCCP work on encaps.
   draft-tuexen-sctp-udp-encaps-06, January 10, 2011
   Adopted as a work item 21 Sept 2010 (Gorry)
   WG -02 8 Dec 2011
   DUE: New revision need.

draft-ietf-tsvwg-intserv-multiple-tspec
   WG interest in this topic recorded at IETF-78.
   Charter update would be needed to progress this work.
   5 Reviews needed to determine energy/technical direction.
   WG -05 (presented in Beijing, IETF-79)
   WG -06 (presented in Prague, IETF-80)
   RSVP directorate was consulted.
   2 reviews from RSVP-DIR received (Bruce Davie, ?)
   2 additional reviews promised (Ken Carlberg, Francois LeF)
   Chairs asked AD for a Charter update (IESG agreed)
   Draft discussed at IETF-80, and request to update charter agreed
   - AD advised 4 named reviewers will be required
   Adopted for progression as PS, for May 2012

draft-ietf-tsvwg-rsvp-pcn
   Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn
   WG interest in this topic recorded at IETF-81.
   Individual -01, 2011-07-11
   AD decision allowed this to be added to the milestones
   The document was adopted
   WG -00 8 Oct 2011
   DUE: New revision need

-------------------------------------------------------------------

WG action required:

draft-touch-tsvwg-port-use-00
   - Intended to be advice to protocol designers needing a port.
   5 people have looked at this document, Prague IETF-80
   Individual -01 July 2011
   IETF-81 insufficient feedback from WG at this time.
   WG needs to assess if the new draft should be a work item.
   IETF-82, discussed - Chairs will ask WG to consider.
   DUE: Chairs need to assess energy for work on this topic.
   Please comment on list.

draft-nishida-tsvwg-sctp-failover
   Individual-00 Presented in Prague, IETF-80.
   - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath
   DUE: New revision need.

draft-tuexen-tsvwg-sctp-multipath
   -00 Presented in Prague, IETF-80.
   - understood not to conflict with draft-nishida-tsvwg-sctp-failover
   -01, 2010-12-27
   Please comment to list.

draft-tuexen-tsvwg-sctp-sack-immediately
   -05, 2011-01-02
   - Aug 2011, discussed on list and issues raised.
   DUE: Chairs need to confirm adoption (need to do work).
   DUE: New revision need (to address comments)
   Please comment on list.

-------------------------------------------------------------------

The following have received recent discussion at TSVWG meetings or on
the list. Inclusion in the list below does not indicate support for
these specific drafts and other contributions are also warmly welcomed.

draft-stewart-tsvwg-sctpecn-00
   Partially replaces (draft-stewart-tsvwg-sctp-nonce)
   IETF-78 suggested there was interest in this topic.
   Please comment to list.
   Revised uploaded with new name.
   - The draft needs to be updated for multihoming (IETF-80)
   - new revision expected April 2011 (IETF-80)
   WG needs to assess if the new draft should be a work item.
   Please comment on list.

draft-briscoe-tsvwg-ecn-encap-guidelines
   -00 Presented in Prague, IETF-80.
   - comments at IETF-80 (see minutes)
   WG needs to assess if the new draft should be a work item.
   Please comment on list.
   DUE: Chairs to check liaison status with other SDOs.

draft-carlberg-tsvwg-ecn-reactions
   Reactions to Signaling from ECN Support for RTP/RTCP
   -00 presented IETF-82
   WG needs to assess if the new draft should be a work item.
   Please comment on list.
-------------------------------------------------------------------

draft-polk-tsvwg-rsvp-app-id-vv-profiles
   -01 Presented in Beijing, IETF-79.
   -02, 14-Mar-2011
   Presented IET-80.
   WG needs to assess if the new draft should be a work item.
   Seek to coordinate with music with partner ID:
     draft-polk-mmusic-traffic-class-for-sdp
   Please comment on list.
   DUE: Chairs to liaise with MMUSIC WG (Gorry).

draft-lefaucheur-tsvwg-rsvp-multiple-preemption
   RSVP directorate to be consulted.
   - Reviewers: Bruce Davie (awaiting other reviews)
   Please comment to list.

draft-wing-tsvwg-happy-eyeballs-sctp
   This appears dead.

-------------------------------------------------------------------

Related non-WG items:

draft-ietf-behave-sctpnat-03.txt
   BEHAVE WG item linked to SCTP encapsulation work.

draft-ietf-6man-udpzero
   Previoiusly: draft-fairhurst-tsvwg-6man-udpzero
   Draft was adopted by 6man, please discuss on the 6man list.
   A WGLC of this draft is expected in 6MAN WG.
   Related draft: draft-ietf-6man-udpchecksums-00
   Expected to start WGLC early 2012.
   This draft will be LC'ed in TSVWG also.

------------------------------------------------------------------

Other news:

RSVP Directorate (formed in May 2010)
Charter updated Aug 2011.

------------------------------------------------------------------

TSVWG meeting minutes from IETF-82 (TAIPEI)

The Chairs have checked the notes and audio record, and propose the 
minutes below for the Taipei TSVWG meeting.

Does anyone know of any corrections to these notes, or are they 
acceptable to the group?

Best wishes

James and Gorry
(TSVWG Co-Chairs)

------

TSVWG Meeting Notes
IETF 82 (TAIPEI)
Meeting Chair: Wes Eddy (TSV AD).
WG Chairs: Gorry Fairhurst & James Polk

Agenda

* Working Group Drafts

   Jukka Manner
   draft-ietf-tsvwg-byte-pkt-congest

* Non-Working Group Drafts

   Ken Carlberg - Reactions to Signaling from ECN Support for RTP/RTCP
   draft-carlberg-tsvwg-ecn-reactions-00

   Joe Touch - Recommendations for Transport Port Uses
   draft-touch-tsvwg-port-use

   Joe Touch - Shared Use of Experimental TCP Options
   draft-touch-tcpm-experimental-options-00

   Michio Honda - Towards Extending the TCP Option Space

---
draft-ietf-tsvwg-byte-pkt-congest - Jukka Manner

Document received feedback and has been updated. The authors
would like to move to WGLC.

---
draft-touch-tsvwg-port-use

A quick hum was taken on whether or not this document should be
adopted as a TSVWG working group document.  The consensus of the
room seemed to be YES, though this needs to be confirmed on the
mailing list.

Mirja Kuehlewind: Who is the document addressed to?
Joe: Anybody who wishes to apply for a port number or use a
port number in a new way.
Brian Carpenter: I noted you mentioned deprecation of the
system/user port boundary. This seems like a disjunct issue.
Joe: I do not like too many documents, we should check with
the WG on the best way forward.

---
draft-carlberg-tsvwg-ecn-reactions-00

This draft should be taken to the mailing list for discussion;
not many people in the meeting room had read it yet, though
there was interest in continuing to discuss the topic.

Colin Perkins noted related work on RTCweb and a related
AVT draft to communicate feedback information.

It is good to note the options, but we should be careful
about developing new methods.

Bob Briscoe (via jabber): Does it also include loss?
Ken: Not at the moment, comments welcome.

---
draft-touch-tcpm-experimental-options-00

Joe presented this document in TSVWG since the problem of
supporting "experiments" includes other topics in addition
to the TCPM options kind numbers that the document currently
focuses on.

Scope of this document was discussed to determine whether it
should remain TCP-focused and be handled in TCPM, or whether
it was more appropriate for TSVWG or an even broader group.
It was also suggested that the document should motivate use
of assigned ports.
A hum was taken, though it may have been confusing; consensus
seems to be to handle this in TCPM focused on the options
issue.

---
Michio Honda gave a teaser presentation on his work testing the
use of TCP options through middleboxes that will be presented
at the IRTF open session.

----

Notes updated by G Fairhurst from the audio archive and circulated
to mailing list 19-Jan-2012.

RE: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt

Hi Karen,

Sorry for my very slow response. I've thought about this a bit more.
If you have comments or if I miss something, please let me know.

First, I would like to start from a scenario which PF increases error
count aggressively.
Let's assume we have an SCTP association consists of 2 paths and have
one outstanding packet. Now, I would like to think about the following
2 cases for this.

case 1: 1 path became unavailable and after for a while the 2nd path
became unavailable.
case 2: 2 paths became unavailable simultaneously

In case of case 1, if HB is on, SCTP detects an unavailable path and
mark them as inactive
eventually. consecutive error count is 0 until the 2nd path becomes unavailable.
Hence, PF and RFC4960 will have the same behavior in this case, so I
think we can exclude this.

Now, in case of case 1 without HB or case 2, I think RFC4960 behavior
will be like this:
   1: if t3-rtx expires doubled RTO for the destination address
   2: increase consecutive error count. if it exceeds AMR, terminate
the association
   3: choose one of paths (probably by round-robin) as new destination
of retransmission
   4: send a retransmit packet and start t3-rtx timer.

Even if the association goes into dormant state during this cycle, I
think the behavior will be
mostly similar.

In case of PF, the behavior will be something like this:
   1: if t3-rtx expires doubled RTO (data or HB) for the destination address
   2: increase consecutive error count. if it exceeds AMR, terminate
the association
   3: choose active path for new destination of retransmission. if
there is no active path,
       choose one of paths in PF state (probably by round-robin).
   4: send a retransmit packet and start t3-rtx timer.
   5: send a HB on the path where t3-rtx is not running and start t3-rtx.

So, the step 5 is the reason for the aggressiveness. In order to
address this issue, I think
we have the following 3 options.

Option 1:
   Don't increment consecutive error count when HB transmission is
timed out as you suggested.

Option 2:
   When we have to send data to the destination in PF state, don't
send HB to any PF destination.

Option 3:
   When there's multiple paths in PF state, send one HB at one time.

Here's my opinion on them.
I prefer not to do option 1 in PF. It seems to me that this should be
discussed for RFC4960
rather than PF. I would like to keep PF to be consistent with RFC4960
with regard to this.

So, I prefer option 2 or 3 although I don't have a strong opinion yet.
Or, we can adopt both option 2 and 3 if necessary.

Thanks,
--
Yoshifumi Nishida

2011/12/8  <Karen.Nielsen at tieto.com>:
> Hi,
>
> One additional comment to the draft.
> Not sure about whether it has been raised already though.
>
> The aggressive HBs sent on a potentially failed destination address should not contribute
> to the association overall error counter. I.e., a failed HB should not increment the associations error counter.
>
> At least that it how I firmly believe that things should be as the robustness of the
> association error count should not be impacted by the more aggressive HB probing
> (Also simply following the approach of RFC4960 Path Verification. 5.4 of RFC4960)
>
> Would it be possible to have this explicitly clarified in the draft ?
>
> Thanks.
> BR, Karen
>
> -----Original Message-----
> From: tsvwg-bounces at ietf.org [mailto:tsvwg-bounces at ietf.org] On Behalf Of Yoshifumi Nishida
> Sent: 16. september 2011 10:22
> To: tsvwg
> Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
>
> Hi folks,
>
> Based on the michael's review, we have updated the sctp failover draft.
> We believe we addressed the comments we got so far.
>
> Please let us know if we overlook something or if you have more comments.
>
> Thanks,
> --
> Yoshifumi Nishida
> nishida at sfc.wide.ad.jp