Subject: [tsvwg] TSVWG Status Update December 2013

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Dec 2013 14:30:19 +0000

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,

Gorry, David & James
(TSVWG Chairs)
Sept 2013

---
Recently published:
draft-ietf-tsvwg-sctp-udp-encap was published as RFC 6951.
draft-ietf-tsvwg-sctp-sack-immediately was published as RFC 7053.

-------------------------------------------------------------------
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.

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

WG Drafts with Chairs:

‘Multicast UDP Guidelines’ as a BCP RFC - Document Shepherd: Gorry

- WG needs to consider drafts and identify reviewers.

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

WG Drafts:
---
draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James

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 PCN R
RSVP-DIR review received (BB, KC).
DUE: WGLC concluded Friday, August 23rd, 2013.
Nov 2013,
DUE: new ID required to address RSVP model and then repeat WGLC

---
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
DUE: Next step WGLC
DUE: Please read sections and provide feedback!
---
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)
DUE: Expected ready for WGLC;
DUE: Reviewers are needed to prepare for a WGLC.
---
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.
DUE: Authors please update following comments and align to related draft 
on SCTP NAT.
DUE: Please comment on list
++ Dan Wing has committed to review this.
---
draft-ietf-tsvwg-sctpnat
Replaces: draft-ietf-behave-sctpnat-03.txt
Adopted Nov 2013.
Former BEHAVE WG work item that defines SCTP NAT support
DUE: Authors please update to align to related draft on SCTP NAT.
DUE: Please comment on list
---
draft-ietf-tsvwg-requirements-update-00
Replaces: draft-ietf-behave-requirements-update-00
Nov 2013, Former BEHAVE WG work item intended for publication as a BCP
DUE: Please comment on list
++ Dan Wing has committed to review this.
---
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: Please comment on list.
---
draft-ietf-tsvwg-sctp-dtls-encaps - 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.
DUE: Please comment on list.
---
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: Discussion needed on list.
---
draft-ietf-tsvwg-sctp-prpolicies
replaces: draft-tuexen-tsvwg-sctp-prpolicies
Nov 2013, Adopted SCTP PR Polices intended for publication as a PS RFC
---
draft-ietf-tsvwg-sctp-ndata
replaces: draft-stewart-tsvwg-sctp-ndata-03
Nov 2013, Adopted , intended for publication as a PS RFC

-------------------------------------------------------------------
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-shepherd-multicast-udp-guidelines -  Multicast UDP Usage 
Guidelines for Application Designers
Announced at Orlando, IETF-86, Mar 2013 (no presentation)
- Thought to fall within TSVWG charter, milestone created.
- Authors requested TSVWG adoption.
DUE: Please comment on list.

---
draft-briscoe-tsvwg-ecn-encap-guidelines - Document Contact: Gorry
-00 Presented in Prague, IETF-80.
- comments at IETF-80 (see minutes)
Authors need to update this draft.
New ID presented in Atlanta, IETF-85.
ID presented in IETF-88.
- Authors requested TSVWG adoption.
DUE: Please comment on list.
---
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.
DUE: Please comment on list.
---
draft-dhesikan-tsvwg-rtcweb-qos
- RTCweb and QoS Markings
- Authors requested TSVWG adoption.
Chairs: Who has read the draft? (lots 10's of people)
Chairs: Who thinks it is important to do work in the IETF? (Many)
I-D updated after initial TSVWG feedback
DUE: comment on list.
---------------------------------------------------------------

Individual drafts recently discussed in TSVWG:

draft-tuexen-tsvwg-sctp-multipath (CMT)
-00 Presented in Prague, IETF-80.
- understood not to conflict with draft-nishida-tsvwg-sctp-failover
- Implemented in FreeBSD (ns2, inet)
- subsumes NR-SACK
-01, 2010-12-27
DUE: Please comment to list.
DUE: Need to decide if this can be adopted as a WG Item
---
draft-polk-tsvwg-rfc4594-update - Document Contact: David
Discussed at IETF-83, Paris
Noted at IETF-84, but not discussed (no time).
ID-discussed at IETF-85.
DUE: Please comment on list.
---

draft-polk-tsvwg-new-dscp-assignments - Document Contact: David
- noted at IETF-84, but not discussed (no time).
Linked to above
DUE: Please comment on list.
---

---

From: <[email-masked]>
Date: Wed, 18 Dec 2013 08:55:23 +0100

Hi Gorry,

my small contribution to discuss the TSVWG input:

draft dhesikan -03 is a rather short document. It is now focused on IP DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP QCI related discussion has been removed.

The authors of draft dhesikan prefer to support a wide set of DSCPs and suggest to support different levels of priority. The introduction seems to say, it is largely considered to be applied within LANs, for home gateway internal classification and for Wifi. That's fine with me.

In the case of traffic sent to a network provider broadband access router / network gateway, I doubt that too many markings make sense. I'd expect the network provider routers or gateways not to trust DiffServ markings sent by a consumer device. The draft doesn't mention that. Adding such a note may be useful. 
As I'm known for simplistic approaches, my take is to mark traffic sent by a home gateway to a provider policy point by two DSCPs only, Best Effort and an AF PHB. I agree however with the authors, that a Home Gateway could and should internally apply a much more fine grained QoS differentiation for upstream traffic. If all home network devices apply proper markings as suggested by the authors, this may help.

If there's interest to approach the 3GPP community for a discussion on a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. This should be documented in a separate draft, as I'd expect this inter SDO work to consume a fair amount of time.

Regards and seasonal greetings,

Ruediger

---

From: [email-masked]
Date: Wed, 18 Dec 2013 11:28:08 -0000

See a few thoughts in-line (with no chair-hat):

> draft dhesikan -03 is a rather short document. It is now focused on IP
> DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP QCI
> related discussion has been removed.
>
> The authors of draft dhesikan prefer to support a wide set of DSCPs and
> suggest to support different levels of priority. The introduction seems to
> say, it is largely considered to be applied within LANs, for home gateway
> internal classification and for Wifi. That's fine with me.
>
> In the case of traffic sent to a network provider broadband access router
> / network gateway, I doubt that too many markings make sense. I'd expect
> the network provider routers or gateways not to trust DiffServ markings
> sent by a consumer device. The draft doesn't mention that. Adding such a
> note may be useful.
>
Personally I'd agree - it would be useful to describe this context

> As I'm known for simplistic approaches, my take is to mark traffic sent by
> a home gateway to a provider policy point by two DSCPs only, Best Effort
> and an AF PHB. I agree however with the authors, that a Home Gateway could
> and should internally apply a much more fine grained QoS differentiation
> for upstream traffic. If all home network devices apply proper markings as
> suggested by the authors, this may help.
>

I think it would be useful to say that each DSCP by a single app require a
way for the app or transport to know which work appropriately along that
path. Especially when traffic is dynamically moved between different PHB
groups.

The fact that many deployed networks support a small set of DSCPs is worth
I think a mention. To me this has some implications, e.g. when the App
sets EF or CS1 and networks supports just AF and BE - intended precedence
would then rely upon correct treatment or re-marking. If this were not
appropriate, then the loss will depend upon whether it was before or after
the DSCPs were interpreted as intended.

> If there's interest to approach the 3GPP community for a discussion on a
> useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. This
> should be documented in a separate draft, as I'd expect this inter SDO
> work to consume a fair amount of time.
>
Gorry

---

From: "Nguyen, An P" <[email-masked]>
Date: Wed, 18 Dec 2013 18:09:55 +0000

James,

After I quickly scanned through Section 5 - DSCP Mappings of the draft-dhesikan-tsvwg-rtcweb-qos03, I have a question for you:
I wonder if this section could be expanded to include RFC 5856  - A Differentiated Services Code Point (DSCP)
for Capacity-Admitted Traffic?

Respectfully yours,

An Nguyen
DHS/OEC ( Formerly known as NCS)

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 18, 2013 6:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos

See a few thoughts in-line (with no chair-hat):

> DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP 
> QCI related discussion has been removed.
>
> The authors of draft dhesikan prefer to support a wide set of DSCPs 
> and suggest to support different levels of priority. The introduction 
> seems to say, it is largely considered to be applied within LANs, for 
> home gateway internal classification and for Wifi. That's fine with me.
>
> In the case of traffic sent to a network provider broadband access 
> router / network gateway, I doubt that too many markings make sense. 
> I'd expect the network provider routers or gateways not to trust 
> DiffServ markings sent by a consumer device. The draft doesn't mention 
> that. Adding such a note may be useful.
>

> As I'm known for simplistic approaches, my take is to mark traffic 
> sent by a home gateway to a provider policy point by two DSCPs only, 
> Best Effort and an AF PHB. I agree however with the authors, that a 
> Home Gateway could and should internally apply a much more fine 
> grained QoS differentiation for upstream traffic. If all home network 
> devices apply proper markings as suggested by the authors, this may help.
>

I think it would be useful to say that each DSCP by a single app require a way for the app or transport to know which work appropriately along that path. Especially when traffic is dynamically moved between different PHB groups.

The fact that many deployed networks support a small set of DSCPs is worth I think a mention. To me this has some implications, e.g. when the App sets EF or CS1 and networks supports just AF and BE - intended precedence would then rely upon correct treatment or re-marking. If this were not appropriate, then the loss will depend upon whether it was before or after the DSCPs were interpreted as intended.

> If there's interest to approach the 3GPP community for a discussion on 
> a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. 
> This should be documented in a separate draft, as I'd expect this 
> inter SDO work to consume a fair amount of time.
>
Gorry

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Thu, 19 Dec 2013 17:27:51 +0000

Thank you for your comments, Ruediger and Gorry.

Inline as SD:

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 18, 2013 3:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos

SD:  Sounds good. I will add a statement or two on lack of trust of client devices and the effect on DSCP marking. 

In addition, I am expecting there will be some work done on the authorization mechanisms for webrtc traffic that will allow some off-path authorization of DSCP for particular flows.

SD: ack. Yes, it is possible to add an example or two on how the DSCPs defined in this document can be treated in a network that has only 2-4 PHBs.

> inter SDO work to consume a fair amount of time.
SD: I will also participate as needed. 

Regards,
Subha
Gorry

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Thu, 19 Dec 2013 17:34:22 +0000

Thanks An Nguyen. I am sure James will share his thoughts but here is what my thoughts were when I prepared the document:

I did deliberate on whether the high priority category of the voice traffic should be left aside for admitted EF.  I decided against it eventually because admitted-EF brings with it the requirements of admission control.   Since there is no admission control mechanisms or discussions in this draft, it led to my decision to leave it out.

I believe we can discuss further on the use cases for admitted traffic in webRTC and if needed, introduce the conditions and marking of traffic with admitted EF to a separate document.

Regards,
Subha

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Nguyen, An P
Sent: Wednesday, December 18, 2013 10:10 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos

James,

After I quickly scanned through Section 5 - DSCP Mappings of the draft-dhesikan-tsvwg-rtcweb-qos03, I have a question for you:
I wonder if this section could be expanded to include RFC 5856  - A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic?

Respectfully yours,

An Nguyen

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 18, 2013 6:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos

Gorry