Subject: [tsvwg] Updated TSVWG Status 5th June 2014

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 05 Jun 2014 11:56:26 +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. Please also ensure the 
chairs are aware of any intended new submissions.

Gorry, David & James
(TSVWG Chairs)
June 2014

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

Recently published:

None

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

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

draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry

-------------------------------------------------------------------
IDs in IESG processing:

None

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

New proposed work:
draft-eggert-tsvwg-rfc5405bis (to be submitted)
draft-fairhurst-tsvwg-circuit-breaker (adoption request on tsvwg list)
draft-wing-tsvwg-turn-flowdata-00.txt (to be discussed, Toronto).

-------------------------------------------------------------------
WG Drafts with Chairs:
draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James/David

Replaces: draft-karagiannis-pcn-tsvwg-rsvp-pcn
AD decision allowed this to be added to the milestones
Document adopted, status will be EXP (IETF-84 due to dependencies on RSVP)
RSVP-DIR review received (BB, KC).
WGLC concluded Friday, August 23rd, 2013.
Nov 2013, Next step new ID required to address RSVP model and then 
repeat WGLC Document revised. Francois added as author.
No noted disagreement from WG.
Mar 2014, WGLC started on the updated text. Scott Bradner commented on 
document in WGLC.
Chairs: Write-Up needed (last update February 14, 2014) - David will do.
---
draft-ietf-tsvwg-port-use - Document Shepherd: Gorry

Replaces: draft-touch-tsvwg-port-use-00
- Intended to be advice to protocol designers needing a port.
5 people looked at this document, Prague IETF-80
Individual -01 July 2011
IETF-81 insufficient feedback from WG at this time.
IETF-82, discussed.
Adopted by WG Presented IETF-86, March 2013
Milestone updated to June 2014
Mar 2014, Chairs WGLC to be started after current WG actions.
- IANA review comments received
- Sent review requests to RAI, APPS, and SEC areas during 1st WGLC.
+ Comments May 2014: Paul Hoffman; Lars Eggert; IANA; David Black;
5 Jun 2014, WGLC completed - comments received,
DUE: Revised ID needed.
-------------------------------------------------------------------

WG Drafts
---
draft-ietf-tsvwg-sctp-prpolicies - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-prpolicies
Nov 2013, Adopted SCTP PR Polices intended for publication as a PS RFC
March 2014, Next revision expected for WGLC.
Gorry read 20-May-2014 - needs to be PS
Revised ID May 2014.
DUE: MILESTONE PASSED, WGLC due.
DUE: Waiting for final version from Authors
- Reviewers needed to read (e.g. those who want this!!!)
---
draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01
WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD}
[Milestone: Jan 2014, PS] Implemented in Firefox (FF21).
Required by RTCweb. Comments received.
++ Eric Rescorla has committed to review this.
DUE: A security review during WGLC of next revision.
++ Comments from Joe Touch (draft to be updated)
DUE: MILESTONE PASSED
DUE: Waiting for final version from Authors
DUE: Please comment on list.
---
draft-ietf-tsvwg-natsupp-tsvwg - Document Shepherd: James
Replaces: draft-stewart-natsupp-tsvwg
Dependency from BEHAVE WG.
Adopted as a work item 21 Sept 2010 (Gorry).
WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg
Authors restructured draft (-03)
Added support for single and multi-homed support.
IETF-86: 3 people in meeting had read -04 or -05.
Feb 2014, Authors please update following comments and align to related 
draft on SCTP NAT (conflicts found in language)
Chairs: - authors have requested a single document to replace both.
++ Dan Wing has committed to review this.
++ Fred Baker has committed to review this.
Chairs: We plan to start a WGLC in the period up to July 2014.
---
draft-ietf-tsvwg-sctpnat - Document Shepherd: Gorry
Replaces: draft-ietf-behave-sctpnat-03.txt Adopted Nov 2013.
Former BEHAVE WG work item that defines SCTP NAT support
Feb 2014, Authors please update following comments and align to related 
draft on SCTP NAT (conflicts found in language)
Chairs: - authors have requested a single document to replace both.
++ Fred Baker will review next version.
 >> separated the simpler case for single-homed use - this separation 
should be clearer
DUE: Chairs to consider if combining two IDs would simplify the document
---
draft-ietf-tsvwg-behave-requirements-update - Document Shepherd: David
Replaces: draft-ietf-behave-requirements-update-00
Nov 2013, Former BEHAVE WG work item intended for publication as a BCP
Mar 2014, Irene R reviewed this and found no conflict with SCTP drafts.
Some suggestions (in no particular order) for a shepherd:
++ Dave Thaler, may review, as former behave co-chair
++ David Harrington, has been around in behave, and he knows how to do 
this and volunteered multiple times.
++ Ask Jana to review this.
++ Dan has committed to review this.
Chairs: Check intention and planned timeline.
DUE: Please comment on list
---
draft-ietf-tsvwg-sctp-failover - Document Shepherd: James
Replaces: 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
Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP]
DUE: March 2014, Chairs to consider if PS status is appropriate
DUE: Please comment on list.
---
draft-ietf-tsvwg-sctp-ndata - PS
- replaces: draft-stewart-tsvwg-sctp-ndata-03 Nov 2013,
Adopted , intended for publication as a PS RFC
Mar 2014, 5-6 people had read.
DUE: Revised ID needed.
---
draft-tsvwg-gre-in-udp-encap - PS Document Shepherd: David
- replaces: draft-yong-tsvwg-gre-in-udp-encap
Dec 2013, Adopted , intended for publication as a PS RFC
Feb 2014, discussion of scope and applicability of circuit breakers
Mar 2014 consider MUST implement, SHOULD use in these environments for CB
DUE: Revised ID needed, waiting on RTG AD text for 
draft-ietf-mpls-in-udp draft that will also be used in this draft.
---
draft-ietf-tsvwg-rtcweb-qos - PS - Document Shepherd: David
- Replaces: draft-dhesikan-tsvwg-rtcweb-qos
- RTCweb and QoS Markings
- Authors requested TSVWG adoption.
- Who has read the draft? (lots 10's of people)
25-Mar-2014, Adopted by tsvwg
- Who thinks it is important to do work in the IETF? (Many)
I-D updated after initial TSVWG feedback
Mar 2014, Adoption call (strong support in WG meeting London)
Adoption call concluded 24 Match 2014: intended as a PS RFC for Sept 2014
++ Magnus agreed to review this.
Mar 2014, Please subscribe to "DART" for other related discussions. DART 
draft will need to be in good shape (WGLC?) before we can WGLC this 
rtcweb-qos draft.
DUE: Please comment on list, see IETF DART WG.
---
draft-ietf-tsvwg-ecn-encap-guidelines - Document Contact: Gorry
replaced draft-briscoe-tsvwg-ecn-encap-guidelines
-00 Presented in Prague, IETF-80.
- comments at IETF-80 (see minutes)
New ID presented in Atlanta, IETF-85. ID presented in IETF-88,89
++ forward an appropriate message (perhaps your note to the mailing list 
for approval to adopt) to [email-masked])
++ Reviewers: Andrew McGregor, Dirk Kutscher, Richard Scheffnegger, 
Brian Tramwell.
Mar 2014, WG Call for adoption started, to end 4th March 2014
19 for, 1 against. 8 echoed on the list
Adoption call concluded and document adopted.
* ecn-encap-guidelines and AQM are the main new things they need to know 
about.
on <http://www.ietf.org/proceedings/86/train-3.html>IEEE802.1Q)
DUE: Please comment on list.
---
draft-ietf-tsvwg-rsvp-app-id-vv-profiles
Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles
-01 Presented in Beijing, IETF-79.
-02, 14-Mar-2011
Presented IETF-80.
Seek to coordinate with music with partner ID:
draft-polk-mmusic-traffic-class-for-sdp
Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from 
this tsvwg draft).
Adopted as a TSVWG work item, December 2013, [Milestone Jul 2013].
This will update a RFC 2872 (PS).
Presented at IETF-86,
Mar 2013 (no comments)
Expected ready for WGLC (waiting on MMUSIC)
DUE: Reviewers are needed to prepare for a WGLC
-------------------------------------------------------------------
Expired WG documents:
---
draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David
WG interest in this topic recorded at IETF-78.
Charter update 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)
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 name: 'RSVP Multiple Instance'.
DUE: 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.
---------------------------------------------------------------
Authors request to be considered for adoption
---
draft-geib-tsvwg-diffserv-intercon-02.txt - Document Contact: David
DiffServ interconnection classes
New ID presented in Atlanta, IETF-85.
ID presented in Orlando, IETF-86, Mar 2013. Mar 2014, intended scope 
unclear at IETF London Adoption call to be considered, but scope needs 
to be first refined and a revised draft is necessary to avoid 
implications of broader applicability.
DUE: Revised ID to set scope required.
---
draft-eggert-tsvwg-rfc5405bis (To be submitted)
- Individual (Gorry & Lars)
Mar 2014, the ADs proposed the WG re-open the UDP Guidelines RFC for 
update to include this work and other topics.
The authors of both drafts agreed to progress this work.
NOTE: Update milestone in charter, if adopted: ‘Multicast UDP 
Guidelines’ is being incorporated in this.
DUE: Initial draft required
---
draft-fairhurst-tsvwg-circuit-breaker
- Individual (Gorry Fairhurst)
Call for adoption issued - June 2014
DUE: Please comment on list
---
draft-wing-tsvwg-turn-flowdata-00.txt
- Individual
- To be discussed in Toronto (thought to also be relevant to TURN WG)
----

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 09:57:11 +0200

Dear chairs,

draft-ietf-tsvwg-rtcweb-qos

- does not change existing IETF DiffServ specs
- introduces a priority and defines it as:

   The following are the inputs that the browser provides to the media engine:

      o  Data Type: The browser provides this input as it knows if the flow
         is audio, interactive video with or without audio, non-interactive
         video with or without audio, or data.
      o  Priority: Another input is the relative treatment of the flow
         within that data type.  Many applications have multiple media
         flows of the same data type and often some are more important than
         others.  Likewise, in a video conference where the flows in the
         conference is of the same data type but contains different media
         types, the flow for audio may be more important than the video
         flow.  JavaScript applications can tell the browser whether a
         particular media flow is high, medium, low or very low importance
         to the application.

      When it comes to data transmission, a media (data) flow is the SCTP
      stream under a common congestion control (currently within the same
      SCTP association).

And then assigns priorities in table 1:

   Table 1

      The columns "very low", "low", "Medium" and "high" are the priority levels.

I'd appreciate a clarification on how that corresponds with the DiffServ architecture, 
RFC2575:

   This architecture is composed of a number of functional elements
   implemented in network nodes, including a small set of per-hop
   forwarding behaviors, .... This architecture achieves scalability by implementing
   complex classification and conditioning functions only at network
   boundary nodes, and by applying per-hop behaviors to aggregates of
   traffic which have been appropriately marked using the DS field in
   the IPv4 or IPv6 headers [DSFIELD].  Per-hop behaviors are defined to
   permit a reasonably granular means of allocating buffer and bandwidth
   resources at each node among competing traffic streams.  Per-
   application flow or per-customer forwarding state need not be
   maintained within the core of the network.

Please clarify whether a browser is network boundary node in the sense of RFC2575. 
And whether DiffServ has been designed to "tell the browser whether a particular media 
flow is high, medium, low or very low importance to the application."

While looking into the DiffServ WG archive, I also found http://tools.ietf.org/html/rfc3140 .
The approach taken there may be helpful in exchanging "intended PHB" information in 
environments, where codepoints may change. Just as an info, no request to be applied.

This mail doesn't state right or wrong - I'd just like to understand what 
DiffServ is about and especially, what an "aggregation of traffic" means. From 
discussion about draft-york-dart-dscp-rtp-00, I've learned, that a fair number 
of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow and this starts 
to put my interpretation of DiffServ somewhat off track.

Regards,

Ruediger

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 11 Jun 2014 16:56:48 +0200

Hi Ruediger and all,

> Please clarify whether a browser is network boundary node in the sense of RFC2575. 

You mean the DS boundary node mentioned in RFC2475 I guess.
My interpretation is: if the end-system on which the browser resides
is "trusted" then it can be considered as being a DS boundary node,
because it sets the initial marking. However, the draft explicitly says:

%   The DSCP value set by the endpoint is not always trusted by the
%   network.  Therefore, the DSCP value may be remarked at the network
%   edge through policy to any other DSCP value, including best effort.

This is clear enough IMHO.
The main weakness of DiffServ is that once the flow has entered
the DS region, you have to deal with it - there is normally no way
to punish/push back single "misbehaving flows".

> flow is high, medium, low or very low importance to the application."

No, DiffServ was designed to be application-independent and only
distinguishes between different behavior aggregates. By using the
mapping table this is indirectly reflected by using different
DSCPs/PHBs. I don't see any problem here.

> environments, where codepoints may change. Just as an info, no request to be applied.

Correct, and indeed it would be better to signal PHB-IDs, but this
cannot be done within the packets, one would need an extra signaling
protocol for this.

> to put my interpretation of DiffServ somewhat off track.

The DS architecture does not preclude using a multi-field classifier
that goes beyond the 5 tuple classifier (identifying a micro-flow in
DS terminology). It's actually more work for the classifier within the
DS boundary node. The DS architecture doesn't forbid to have a
micro-flow with different DSCP markings in it, but it is mentioned
several times that packet reordering within a micro-flow due to that
different marking should be avoided.

I have more comments w.r.t. the draft and will write another e-mail
for that.

Regards,
 Roland

-- 
PD Dr. Roland Bless -- WWW: http://tm.kit.edu/~bless
Institut für Telematik, Karlsruher Institut für Technologie (KIT)
Postf. 6980, 76049 Karlsruhe -- Zirkel 2, Geb. 20.20, 3.OG, Raum 358
Tel.: +49-721-608-46413 Mob.: +49-152-0160-1400 Fax: +49-721-608-46789

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 15:42:08 -0400

<WG chair hat OFF>

I'll respond anyway as one of the original designers of DiffServ.

draft-ietf-tsvwg-rtcweb-qos is about mapping from an application
API to network functionality.  The media engine is not part of the
application - it's part of the browser or other application framework.
That draft is concerned with how the browser or other framework
determines the initial DSCP marking to apply to packets that it
sends (well, asks the system that hosts it and the application to
send).

> Please clarify whether a browser is network boundary node in the

That would be RFC 2475 ;-).

A browser is definitely not a network boundary node (FWIW, I'm one
of the authors of RFC 2475) - the first network boundary node that
a packet encounters will usually be after a DSCP-marked packet
is sent by (and leaves) the system on which the browser is running. 

> And whether DiffServ has been designed to "tell the browser whether a
> particular media flow is high, medium, low or very low importance to
> the application."

No, it was not; a browser is not a network node.  That statement in
that draft is about the API between an application and browser or
other framework, which is outside of any DiffServ domain.

> The approach taken there may be helpful in exchanging "intended PHB"
> information in environments, where codepoints may change. Just as an
> info, no request to be applied.

I actually prefer the approach in draft-ietf-tsvwg-rtcweb-qos, as it
insulates PHB selection and details from application programmers,
presenting them with a simpler, more abstract model.

> DiffServ is about and especially, what an "aggregation of traffic" means.
> From discussion about draft-york-dart-dscp-rtp-00, I've learned, that a
> fair number of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow
> and this starts to put my interpretation of DiffServ somewhat off track.

That mixing of PHBs on a single UDP 5-tuple is actually a new concept -
draft-york-dart-dscp-rtp-00 picked that concept up from
draft-ietf-rtcweb-transports-05, which contains details on what RTCWEB
intends to do in this area.  That concept should be open to discussion on
the dart list, as this mixing of PHBs on a single 5-tuple (aside from
mixing the PHBs that constitute a single AF class) was not anticipated
in the original DiffServ architecture/design.

Thanks,
--David (co-author of RFC 2475, RFC 3140 and draft-york ... but that
doesn't mean that I know all the answers ...).

</WG chair hat OFF>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2014 3:57 AM
> To: [email-masked]; Black, David; [email-masked]
> Cc: [email-masked]
> Subject: Question about priorities in draft-ietf-tsvwg-rtcweb-qos
> 
> Dear chairs,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 08:35:06 +1200

> other framework, which is outside of any DiffServ domain.

Yes, which is just as well, since diffsev doesn't deal in
priorities (the nearest it gets is the backwards-compatible
precedence classes). An application can legitimately have priorities
between its own packets, because it understands which ones are
more important. But diffserv is blind to application semantics; all
it really does is provide a way of selecting different queueing
disciplines for different traffic streams. Quite how we match those
two worlds together has always been an interesting question, which
I assume will be debated in DART.

    Brian

>> particular media
>> information in