Subject: [tsvwg] TSVWG DRAFT STATUS October 2012

From: [email-masked]
Date: Fri, 19 Oct 2012 11:09:40 +0100

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, Rolf and Gorry
(TSVWG Chairs)

---
Recently published:

draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411.
draft-ietf-tsvwg-sctpsocket was published as RFC 6458.
draft-ietf-tsvwg-sctp-strrst was published as RFC 6535.
draft-ietf-tsvwg-source-quench was published as RFC 6633.

-------------------------------------------------------------------
IDs in RFC Editor Queue:
http://www.rfc-editor.org/queue.html
None.

-------------------------------------------------------------------
IDs in IESG processing:
None.

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

NOTE:
ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison on QoS
Classes & markings for interconnection

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

WG Drafts with Chairs:

draft-ietf-tsvwg-sctp-udp-encap
(Replaced: draft-tuexen-sctp-udp-encap)
Lars sent a note as AD agreeing to progress this work.
Work was coordinated with DCCP work on encaps.
draft-tuexen-sctp-udp-encaps-06, January 10, 2011
Adopted as a work item 21 Sept 2011 (Gorry)
WG -02 8 Dec 2011
WGLC completed Friday 20th April 2012, many discussion and notes that
there were implementations.
13th Oct 2012, comments sent on draft to prepare for submission.
DUE: Revised ID needed prior to AD submission, changes agreed.

---
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 IETF-82 (Taipei), request for WGLC.
Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun 2012).
WGLC concluded with comments on I-D, Friday 30th March 2012.
Draft version of write-up sent to list, comments received.
- Gorry working with authors to clear list of WGLC questions (5 sept 2012)
DUE: WG Chair waiting for version that includes additional feedback during
WGLC

-------------------------------------------------------------------
WG Drafts:

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, status will be EXP (IETF-84 due to dependencies
on PCN RFCs)
WG -00 8 Oct 2011
DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th Oct 2012)

draft-ietf-tsvwg-natsupp-tsvwg
(Replaced: draft-stewart-natsupp-tsvwg)
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/
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
Authors restructured draft (-03)
DUE: Discussion needed on list.

draft-nishida-tsvwg-sctp-failover
Individual-00 Presented in Prague, IETF-80.
- understood not to conflict with draft-tuexen-tsvwg-sctp-multipath
- PF has been coded into FreeBSD
DUE: WG adoption being considered - please comment to list 26/6/2012.
Adopted by WG
DUE: Please comment on list.

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
- New approach presented following WG comments
DUE: Discussion needed on list.

draft-ietf-tsvwg-port-use-00
(replaces 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.
Adopted by WG
DUE: Revised ID expected to complete missing sections

-------------------------------------------------------------------
WG action required:

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
Author requests to make a WG work item...
Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC
early 2013.
Gorry - not much discussion on this list, please assess as a candidate
working document.
DUE: ***PLEASE*** comment on list.

draft-polk-tsvwg-rfc4594-update
- noted at IETF-84, but not discussed (no time).
draft-polk-tsvwg-new-dscp-assignments
- noted at IETF-84, but not discussed (no time).
WG action required (Transport Protocols):

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
DUE: Please comment to 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-carlberg-tsvwg-ecn-reactions
Reactions to Signaling from ECN Support for RTP/RTCP
-00 presented IETF-82
Not yet requested to become a work item.
- This draft is related to the new rmcat work.
DUE: Please comment on 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.

draft-stewart-tsvwg-sctpecn-02
Partially replaces (draft-stewart-tsvwg-sctp-nonce)
IETF-78 suggested there was interest in this topic.
Discussed at IETF-83, Paris.
DUE: ECN is within the TSVWG Charter,
will call for adoption on the list.
DUE: Please comment on list.

draft-polk-tsvwg-rfc4594-update-00
Discussed at IETF-83, Paris
DUE: A Revised ID is needed.

-------------------------------------------------------------------
Related non-TSVWG items:

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

draft-ietf-6man-udpzero
Previously: 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
This draft was also LC'ed in TSVWG (end 3rd May 2012)

draft-ohanlon-rmcat-dflow
Discussed at IETF-84, Vancouver
This draft is related to the new rmcat work.
In IESG discussion on making this a PS for UDP tunnels using IPv6
DUE: Revised ID needed

------------------------------------------------------------------
Other news:

RSVP Directorate (formed in May 2010)
Charter updated Aug 2011.
New co-chair: Rolf Winter <[email-masked]>

ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection

---

From: ken carlberg <[email-masked]>
Date: Fri, 19 Oct 2012 07:36:26 -0400

Hi Gorry,

Thanks for sending the update out to the list.  just a couple of minor corrections on the following...

> DUE: Please comment on list.

at past meetings, we've have made requests for the document to become a working group item.  However, at the same time, since its been a work in progress, we kept finding things to modify/update/clarify.  And while part of the draft is somewhat related to the new rmcat work, its more closely related to rfc-6679 (ECN for RTP over UDP).

So if there are no objections or concerns, I'd like to make a request (on the list this time :-) to make this individual contribution into a working group document.

cheers,

-ken

---

From: [email-masked]
Date: Fri, 19 Oct 2012 13:49:06 +0100

I'll update the status. I also changed the subject - so hopefully people
will see this draft and start to look at this.

I'm keen that we get some feedback from people, and then see this sort of
work progress.

Has anyone on the TSVWG list read this ....

- do people think we should be working on this topic at the IETF?
- what sort of recommendations are needed - and who needs these?
- do you have other ideas or experience that may be relevant?

Gorry

P.S. Ken let's discuss off-line with the co-chairs about the next steps.

> at past meetings, we've have made requests for the document to become a
> working group item.  However, at the same time, since its been a work in
> progress, we kept finding things to modify/update/clarify.  And while part
> of the draft is somewhat related to the new rmcat work, its more closely
> related to rfc-6679 (ECN for RTP over UDP).
>
> So if there are no objections or concerns, I'd like to make a request (on
> the list this time :-) to make this individual contribution into a working
> group document.
>
> cheers,
>
> -ken
>

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 19 Oct 2012 16:04:28 +0200

Hello.

Regarding draft-saldana-tsvwg-tcmtf, the question is that there is a
specific mailing list ([email-masked]), and we are currently discussing
about it there. One of the topics of the discussion is if a Working Group
should be created for it. This is the reason why it does not appear in your
mail, isn't it?

Thank you very much,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> [email-masked]
> Enviado el: viernes, 19 de octubre de 2012 12:10
> Para: [email-masked]
> Asunto: [tsvwg] TSVWG DRAFT STATUS October 2012
> 
> draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item
> 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April
> 2012, many discussion and notes that there were implementations.
> AD decision allowed this to be added to the milestones The document was
> adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG -
> 00 8 Oct 2011
> 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
> 5 people have looked at this document, Prague IETF-80 Individual -01 July
> 2011
working
> document.
> - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01,
2010-
> 12-27
> 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.
> 
> DUE: New revision need (to address comments) Please comment on list.
> 
> Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed
in
> TSVWG (end 3rd May 2012)

---

From: James Polk <[email-masked]>
Date: Fri, 19 Oct 2012 14:45:09 -0500

>should be created for it. This is the reason why it does not appear in your

correct

General question - from your lists's discussions, is there enough 
interested people to think about attempting to form a WG, in your view?

If so, are you having an unofficial meeting (often called a 'Bar 
BoF', that doesn't meet during any other normal session slot to 
maximize attendance) during the Atlanta meeting? This type of meeting 
could demonstrate to the ADs that you might justify an official BoF 
at the next meeting (Orlando). There are some hoops that need to be 
jumped through though. I'm just wondering how far along and how 
organized your topic has come.

James

---

From: [email-masked]
Date: Sat, 20 Oct 2012 08:16:44 +0100

I agree.

At the moment I do not see drafts from this group that look like they are
mature enough to progress within TSVWG. it t is hard to comment further
though until we see a set of drafts that people may read.

Gorry Fairhurst

>> > DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th
>> Oct
>> > 2012)
>> >
>> -01,
>> the

---

From: <[email-masked]>
Date: Mon, 22 Oct 2012 09:31:52 +0200

Gorry,

the topic in general is relevant for IETF, I think. draft-carlberg
mentions that recently the RTP Media Congestion Avoidance Techniques
(rmcat) working group has been set up. It would be useful to understand
how draft-carlberg is related to the scope of the rmcat WG (e.g.
whether draft-carlberg only suggests a basic real time congestion
control mechanism and leaves all further work to rmcat).

Side-note: If congestion control is a chartered task of TSVWG, then there
might be a question whether there's an overlap ov TSVWG and rmcat.

Notes on the draft (in adddition to Bob's ones):

5.1.2 Differentiated Services

   As in the case of RSVP, applications could rely on the reception of CE
   feedback to initiate a subsequent setting of diff-serv code points to
   provide additional protection or explicit association of forwarding
   characteristics of a given flow of packets.  In addition, the setting of
   diff-serv code points would be done on an as-needed basis in reaction to
   CE feedback.  Recommendations concerning specific diff-serv values are
   outside the scope of this document.

It is common to use words like "DiffServ Codepoint" to mean "a QoS class"
(correct DiffServ wording "a PHB <-Group>"). The authors here want to
use an IP QoS class and should say so. There's no standard relation of
DiffServ Codepoints to IP QoS classes (PHB <-Groups>).

Apart from that, I wonder whether an application which had used class X
so far can instantly and seemlessly flip to class Y. Especially, if
there's an expectation of admission control features in a traffic
class, it won't be done with simply marking traffic differently.
Admission Control doesn't mean RSVP to me, it could be measurement
based as well. PCN defines and discussed relevant mechanisms. The
issue here is, that admissiion control is performed prior to setting
up a media session, whereas here, the authors seem to suggest to change
the class of a media session to avoid packet loss and queuing delay.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 19, 2012 2:49 PM
To: tsvwg
Cc: [email-masked]
Subject: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this?

Gorry

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 23 Oct 2012 10:16:21 +0200

Hello, thanks for your feedback.

Regrettably, I will not be able to attend the IETF meeting in Atlanta, so
there will be no possibility for me to organize a "side meeting". Thus, we
will have to work using the mailing lists (according to Scott Bradner's
presentation for newcomers, "most working group work must be done on mailing
lists"). The Euro Zone crisis cannot stop this work. Nevertheless, I will
try to get funds to attend the next one in Orlando. 

In the meantime, we are receiving a lot of feedback in the mailing list
[email-masked], which will be taken into account for the next versions of
the draft(s). So the answer to the question of James is: perhaps the number
of interested people is still low, but it is growing. I have just checked
the archives, and 17 different people have posted something in the list
(http://www.ietf.org/mail-archive/web/tcmtf/current/maillist.html). They are
from 13 different companies or universities. We have even received some
feedback from LISP WG people. 

As James says, we have to "jump through some hoops", but I think we have
already jumped some of them. Thank you very much!

Jose

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] 
Enviado el: sábado, 20 de octubre de 2012 9:17
Para: James Polk
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [tsvwg] TSVWG DRAFT STATUS October 2012

I agree.

Gorry Fairhurst

>>specific mailing list ([email-masked]), and we are currently 
>>discussing about it there. One of the topics of the discussion is if a 
>>Working Group should be created for it. This is the reason why it does 
>>not appear in  your mail, isn't it?
>
> correct
>
> If so, are you having an unofficial meeting (often called a 'Bar BoF', 
> that doesn't meet during any other normal session slot to maximize 
> attendance) during the Atlanta meeting? This type of meeting could 
> demonstrate to the ADs that you might justify an official BoF at the 
> next meeting (Orlando). There are some hoops that need to be jumped 
> through though. I'm just wondering how far along and how organized 
> your topic has come.
>
> James
>
>
>>Thank you very much,
>>
>>Jose
>>
>> > De: [email-masked] [mailto:[email-masked]] En 
>> > nombre
>> de
>> > [email-masked]
>> > The list below shows the status of the working group documents as 
>> > we
>> see
>> > ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison 
>> > on
>> QoS
>> > (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD 
>> > agreeing to progress this work.
>> > ADs & Chairs agree to progress as a BCP Status changed to BCP 
>> > (new-ID WG -05) Presented at IETF-82 (Taipei), request for WGLC.
>> > - Gorry working with authors to clear list of WGLC questions (5 
>> > sept
>> 2012)
>> > adopted, status will be EXP (IETF-84 due to dependencies on PCN 
>> > RFCs)
>> WG -
>> > 00 8 Oct 2011
>> > Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 Authors 
>> > restructured draft (-03)
>> > WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, 
>> > IETF-80) RSVP directorate was consulted.
>> > 5 people have looked at this document, Prague IETF-80 Individual 
>> > -01
>> July
>> > 2011
>> > Gorry liaised with MMUSIC WG Chairs on companion draft, intended 
>> > for
>> LC
>> > early 2013.
>> > DUE: ECN is within the TSVWG Charter, will call for adoption on the 
>> > list.
>> > RSVP Directorate (formed in May 2010) Charter updated Aug 2011.

---

From: ken carlberg <[email-masked]>
Date: Tue, 23 Oct 2012 10:40:59 -0400

Ruediger.

Thanks for your comments.

> might be a question whether there's an overlap ov TSVWG and rmcat.

ok, the previous email I sent out on whether the Reactions draft should be in TSVWG or RMCAT should address this point.

> the class of a media session to avoid packet loss and queuing delay.

several thoughts had come to mind in writing the original text above that were to a degree scenario dependent.  if we're talking about interactive voice/video, one possibility existed in terms of adding EF to the packet when congestion was occuring and potentially incuring an additional "charge" for maintaining the minimal delay characteristics.  This was based on the assumption that the unmarked traffic was still being forwarded with acceptable end-to-end delays during non-persistant congested conditions.  Or, another possibility could be a switch from EF to the EF-admit code point to reflect the added admission control attribute associated with the flow/packet.

Another thought was to possibly use an AF code point for voice/video traffic that was associated with a non-interactive broadcast type of flow that could support a greater end-to-end delay while at the same time trying to minimize loss.  But as we stated in the text, we didn't want to focus on one particular recommendation because these may very per scenario and environment (e.g., public carrier/provider versus private LMR).

cheers,

-ken

ps, my comments to Bob's email will eventually hit the list.  I sent it from another email address, so it will have to be resent by the list monitor.  mea culpa.

---

From: <[email-masked]>
Date: Wed, 24 Oct 2012 08:50:19 +0200

Ken,

it's not relevant which QoS class is used in particular (EF or AF).
My comment didn't relate to a specific QoS class, it relates to QoS
usage in general.
The point is, it's not simply done by setting DiffServ codepoints
in all operational environments. All those where e.g. admission
control is applied will have a mechanism to decide whether an
additional flow can be admitted prior to remarking. This
mechanism must be addressed

You further assume that nothing like QoS aware routing is deployed
(i.e. you assume packets of a flow take the same path independant
of the DSCP). That holds today I guess, but it may not hold
in future.

Wireless 4G networks (on which I'm not an expert!) may neither
allow you to simply change DSCPs nor offer the same delay
properties in different traffic classes.

To sum up: simply changing DSCPs may help in a limited set of
operational environments. Your text should reflect that.

Regards,

Ruediger

cheers,

-ken

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 28 Oct 2012 22:47:40 -0400

> - do you have other ideas or experience that may be relevant?

I've read it.

I think it would be fine to work on in TSVWG, if there's interest,
and if the scope is limited to basically Informational guidance.

I am not personally sure that such recommendations are needed, but
from the range of different reactions the authors describe, I can
see that there's room for someone to make bad decisions and think
they're doing something smart.  So, a document like this *could*
help avoid some of those situations.

As AD for RMCAT, I see this as supplementary, if it was to be
taken up.  RMCAT will do concrete algorithms, and this is more of
a general guidance.  Since RMCAT seems to have kind of a full
plate and aggressive schedule with the existing charter, it may
be a fair idea to handle this in TSVWG, if there's interest.

-- 
Wes Eddy
MTI Systems