Skip to main content

Minutes for TSVWG at IETF-95
minutes-95-tsvwg-7

Meeting Minutes Transport and Services Working Group (tsvwg) WG
Date and time 2016-04-05 17:00
Title Minutes for TSVWG at IETF-95
State Active
Other versions plain text
Last updated 2016-04-10

minutes-95-tsvwg-7
TSVWG Meeting at IETF 95, Buenos Aires

WG Chairs: Gorry Fairhurst and David Black (remote) assisted by Martin
Stiemerling

---- TSVWG Session 1
14:00-16:00 Tuesday Afternoon session I
Note Taker 1: Fred Baker
Notes updated by audio record.

RFC Editor and IESG status:
RFC Editor: AUTH48 draft-ietf-tsvwg-sctp-failover
RFC-EDITOR draft-ietf-tsvwg-behave-requirements-update
Approved-announcement to be sent draft-ietf-tsvwg-circuit-breaker
In Last Call draft-ietf-tsvwg-rtcweb-qos
Publication Requested draft-ietf-tsvwg-rfc5405bis
In WG Last Call draft-ietf-tsvwg-gre-in-udp-encap (extended for 2 weeks to
allow reviews to complete).

draft-ietf-tsvwg-circuit-breaker
Gorry (as author)
Comments have been incorporated and the change to RFC2119 keywords have been
sent to the list. Now to be sent to RFC Editor.

draft-ietf-tsvwg-rtcweb-qos
Updates to be completed after WGLC.

draft-ietf-tsvwg-gre-in-udp-encap
Lucy
Intention is to get some reviews to close the WGLC.
No additional comments.
Three people have volunteered to review within a 2 week extension to the WGLC:
- Donald E
- Martin Stiemerling
- Elliot Lear
Reviews need to be sent to the mailing list.

draft-ietf-tsvwg-sctp-ndata
Michael
The document should be ready for WGLC in the next revision, in 2 weeks.
How many people in the room have read this document? (4+remote people).
Two people have volunteered to review:
- Fred Baker
- Randall Jessup (offer remote)
- Karen Nielson (offer via email)

draft-morand-tsvwg-sctp-parameters-update
Lionel
Use of Diameter over SCTP.
An errata will be submitted to ensure people know of the update, this may be a
suitable editorial clarification. The AD can then decide on how to progress.
Text will also be contributed to the planned update to RFC4960.

draft-tuexen-tsvwg-rfc4960-errata
Michael
How many had read the latest version? (4)
Previous meetings had also reviewed this.
The open issues were reviewed.
Please hum if you would support doing this work in TSVWG? (hum heard)
Please hum if you have concerns about doing this work (or about starting this
work at this time)? (no hum heard) Recommended for working group status, to be
verified by an adoption call on the list.

draft-ietf-tsvwg-natsupp
Michael
TSV started work on NAT for SCTP in the BEHAVE WG and transferred this work
here after that group closed. No concerns were raised with publishing a NAT
document, authors encouraged to complete the work and revise the ID. This will
complete by the milestone.

draft-tuexen-tsvwg-sctp-udp-encaps-cons
Michael
Documents issues now understood with the original RFC.
This is a new draft, please read and comment on the list.
The authors have been suggested to make a .bis document.
Gorry: Do RFCs rely on the UDP encaps document?
Michael: Currently no other RFCs would need to be updated if this document
changes. Gorry: Is this something the WG should do as a WG... please consider
and read the document.

draft-ietf-tsvwg-diffserv-intercon
(Gorry proxy for editors)
No new issues have been found and a revised ID is being prepared.
The ID is expected to proceed to WGLC after the IETF meeting.
Two people have volunteered to review during WGLC:
- Fred Baker
- Robin

There was a notice about up-coming ACCORD BOF on Thursday.

---- TSVWG Session 2
16:20-17:20 Wednesday Afternoon session II
Note Taker: Natasha Rooney
Notes updated by audio record.

7. Agenda Recap

8.  WG Transport Encaps Drafts

8.1 Bob Briscoe - Guidelines for adding Congestion Notification to Protocols
that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines (actually presented
later in the meeting)

Bob Briscoe Presents
Purpose of this draft slide
Liaisons with other groups (layer 2 mostly)
Recent Activity slide
SDOs and groups were identified, we read specs and drafted a response.
3GPP liaison: context slide
We think there may be confusion here. ENodeB (base station) is the context.
3GPP references to ECN
These specs reference ECN. Nearly of these are about ECN/RDP/UDP, these were
fine. RAN references were more problematic. ECN in 3GPP ... slide Not spoken to
3GPP about this yet. Two issues: [1] talking about doing ECN on a node which
isn't IP aware. Should be clearer. [2] marking behaviour is unclear. Gorry: so
this is why we're writing this document! #1 ECN... slide No spec refers to
RFC6040, there must be tunnel nodes, but RFC6040 is not clear on how it covers
GDP so perhaps we need to do something here. Implementation seems unclear. We
will put this into a formal liaison. Martin: Is the work  just on the radio
part? (Bob: Yes). Dirk Mayar: The 3GPP people would thank for the work you did
here! Kevin Smith: Could this help scale things for ConEx? Bob: This would have
same issues, and we do not plan to extend the scope of this particular document
to cover this. #2 ECN...slide Constraint on the behaviour is not specified. ECN
support in TRILL Draft is in WGLC List of ideas how to support ECN in TRILL.
The approach work well because TRILL has been designed with forward
compatibility in mind. Updating Tunnel Specs slide Scope was IP / IP Tunnels,
did not cater for an IP Tunnel with a shim between which can not exist
independently. We wanted to extend scope to cover these cases, we should update
for this. Gorry: We should be careful to add this to the tunnels
recommendations! Erik: We could add a paragraph to routing tunnels ID on the
behaviour we want. Bob: We can only specify how we propagate info between GDP
and IP, as the issue is vendor / machine specific. Gorry: Yes, please write up
as a separate piece of text, so this can be added. Next Steps

Chair Recommendation
Gorry: The intention was to help people understand how to design things in the
way we recommend. Please read the drafts and comment if these seem ready to
publish. Is the advice in this draft being taken-up or appropriate? If this is,
I’d encourage us to finish this document. Bob will reply to the liaison, and
update the draft and write-up a short ID in 1.5 months.

9.  Individual Drafts

9.1 Tim Szigeti - Mapping to 802.11
    draft-szigeti-tsvwg-ieee-802-11
WG Adoption was requested

Fred Baker presents
Changes from -00 to -01
Normalising between this RFC and RFC 4594, specifically on diffserv code points
Question for the group: is this new text ok? (see slides)

Gorry: This draft has been around for some time... It has been presented
several times. It seems within the Charter. Please hum if you would support
doing this work in tsvwg?(hum heard) Please hum if you have concerns about
doing this work (or about starting this work at this time)? (no hum heard)
Gorry: I will take this to the list and we will start an adoption call on the
list at the IETF.

If there is adoption, we expect to also ask immediately for people to review
this draft.

9.2 Bob Briscoe - Identifying Modified ECN Semantics for Ultra-Low Queuing Delay
    draft-briscoe-tsvwg-ecn-l4s-id-00 (actually presented later in the meeting)

Bob Presents
Low Latency slide...
Recap on data centre TCP demo at IETF93
3 parts to standardise draft
We need to look at thing to classify on, looking at a type of ECN.
Choice of identifier slide
We picked the one with the most green boxes!
Meaning... slide
proposing: new service, not update to 3168. Get rid of square root in the
original 3168. If we choose ECT... slide Intended status slide experimental at
the moment, would like a discussion on list for it to move to proposed
standard. Next Steps slide It has been quiet since so we assume everyone
agrees! Gorry: You can't really assume that! Gorry: So please do discuss this
draft on the list.

9.3. Michael Welzl - TCP Alternative Backoff with ECN (ABE)
draft-khademi-alternativebackoff-ecn

Gorry (as Chair): This draft was brought to tsvwg after consultation about
which working group is most appropriate to discuss this draft as an update to
RFC3168.

Michael Presents
Context slide
Proposal is to update ECN, particular the congestion response MUST be the same
as for a single dropped packet. New text in red on the slide Motivation slide
This rule prevents us from using the knowledge which AQM gives us ABE: draft
history slide Question slide

Questions
Michael: Is there interest in adopting an updated draft that updates the
RFC3168 rule? Bob Briscoe: Would you be opposed to adding something more to
RFC3168? E.g., allowing control packets to be updated by ECN? Michael: Not
against this in principle, it depends on how much work is needed. Gorry:
Depends on the maturity of those contributions. Brian: I support this. Is the
PS update just to remove those constraints? Michael: Yes Brian:  What is the
status of the second document? Michael: Not informational, could be EXP. Brian:
please go ahead and get this done. I’m skeptical if we say that we have to
delay to include lots of other things, we could update other aspects in another
update when we are ready. I support this. Erik: Why can you not do both updates
in one document. If you are an implementor it would be easier to have all in
one document. Michael: This split is the approach that the ADs advised this
week. Martin Stiemerling (as AD):  The second document is intended to define
one experimental value. Martin (proxy for Dave Taht via Jabber): Can we look at
the scope of loss and ECN marks within one RTT in this document? Michael: are
we talking about responding to multiple marks in an RTT? Martin: Yes. Michael:
... in this case that’s something different. Markku Kojo: Is there enough
experimentation to make this a PS immediately. There are things that can go
wrong. There could be flight size errors, and issues in fast recovery, when
flight size does not reflect the current pipe. RFC3168 works fine. A second
issue is that small windows may not reduce a full MSS. Markku Kojo: I have a
suggestion: make the reduction of at least one MSS. Gorry: I see the need to
discuss this. Can we get evidence of a safe reduction? (Do you think this is
something to measure, or something that we need to make an engineering decision
upon?) to decide. Markku Kojo: Not sure on the approach. Gorry (Chair): We need
to able to know an algorithm is safe, and I think we need to consider this.
Markku Kojo: Let’s look at specific cases. Gorry: Can people comment on whether
we do this? Mirja: Is this small window reduction also the same for non-ECN? Is
this something for loss and ECN? Markku: This would be new for both cases? Bob:
Stating one number may be too specific. Should be flexible. Gorry (Chair): We
cannot do an adoption call today. I would like to know whether this is
something that this WG needs to consider. Bob: The origins of the RFC3168 text
were to try to be safe. I have not thought how to write this text. I support
the PS not setting a specific value. Fred Baker: At the IETF-94 Bar BoF
discussed an alternative proposal, I think someone had IPR. Michael: This draft
does not have known IPR. Bob: The IPR has not been declared, but does not
relate to this update. Brian: The "New Draft Text" slide is a good start. Needs
some number checking on the number ranges, but this can be changed. Gorry: OK,
the more energy to get the details correct. Mirja: Not sure about the text, I
agree with Bob. I don’t know whether the RFC needs to be updated. Gorry: The
proposal is to update the draft. Is changing 0.5 to 0.7 “essentially” the same.
Mirja: I’m just not sure how we correct we can get this new text.

Chair Recommendation
Gorry: As Chair, I note that people are interested in this. We should find text
for the document that clarifies the intent. Please resubmit the draft and then
we can discuss whether to make it a working group draft, or some other outcome
for the text. Please also split-out the recommended value document. Mirja: I
agree. Please work on this. I would also like more discussion, if we can’t
agree on the details then clearly the WG won’t publish something (personal
opinion). Martin: I agree we should encourage people to take this forward.
Decision: Michael will revise and issue 2 drafts in the next 1-2 months.

Thanks for the final meeting slide Bob!