[Tsvwg] draft TSVWG Minutes - IETF 61

[Allison Mankin <[e-mail]>]

Hi, TSVWG folks,

Here are the minutesfrom the DC meeting - we can update them in
the proceedings, so please send any items for update.  Thank you to
Gorry for the great notes, which I edited only lightly.

Are you "?" in the discussions below?  Identities welcome.

Now the actions from these notes need doing - Jon
and I are reviewing the charter actions; we can't take new working
group drafts without IESG/IAB review, after the WG recommends.  

Allison and Jon

-------- draft ----------

Transport Area WG (tsvwg)

These notes were kindly and expertly scribed by Gorry Fairhurst.
Any errors have been edited in by the Chairs, of course.

TSVWG Wednesday, November 10 at 1530-1730
=========================================

CHAIRS:    
Allison Mankin (AM) <[e-mail]>
Jon Peterson (JP)  <[e-mail]>

* Agenda bashing/Notetaker/Intro (chairs)
JP: No changes.
-------

* RSVP Bandwidth reduction
http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.txt
James Polk 

RSVP sets up reservations based on many properties. Presentation shows how
to reduce the bandwidth of an allocated flow. Open issues - what happens if
ResvErr is not responded to?

Aaron: Why RSVP rather than NSIS?
James Polk: RSVP has running code.
Fred Baker (FB): NSIS has not chosen to work on these issues.
AM: What are the issues we need to work on in NSIS?
FB: Ability to pre-empt, etc.

JP: How many people have read this ID?
A few people.
JP: How many neglected to put their hands up?
None.
AM: I'd like more people to read things.
?: How many people have read the prior version?
Few.
JP: Hum called (among those who had read this).
There was a substantial hum supporting this proposal to the IESG as a
TSVWG work item.

-------

* Wide-Area Network
http://www.ietf.org/internet-drafts/
draft-baker-tsvwg-vpn-signaled-preemption-01.txt

Fred Baker (FB)
Tunnels are common in military networks, and multiple layered tunnels
between enclaves are common. There is a real need to do pre-emption here.
The problem with RSVP is that you would have to traditionally remove the
flow (from a crypto), and all the calls would suffer. Race conditions occur
too. We'd be interested in this also being a WG document.
Joe Touch (JT): In slide 3, you have tunnels over tunnels - and this is
something I am familiar with in the Xbone. In the next slide, this layering
doesn't appear?
FB: This diagram is simpler, read the document, it's recursive.
JT: This has 2 levels?
FB: Yes, this slide. I am telling you the environment that is the reason for
doing what James wants to.

JP: How many people have read the ID?
10 or so.
AM/JP: Would anyone like to support this? Does anyone have views?
?: I have not read this, but from what I see, I would support this.
Jacob: Is the ID in the repository?
JP: Yes, it's there - see the URL on the list. (There was a line-break in
the URL.)

JP: How do we proceed?
?: VPNs are common - both in military and civil nets. RSVP is also becoming
more common.
Aaron Falk (AF): So, here is a process comment: A similar issue came up in
the TCPM WG with an ID and there was a small number of supporters - we
considered a possibility of getting reviewers to assess and report on the
draft, to see if the document was useful to pursue in the group.
?2: There are a small set of people building real solutions, and this
community will benefit from tackling these issues.
JT: If there are not that many people interested in this at this meeting, it
means the IETF is not involved in the issues.
AF: Is this informed apathy or ... apathy?
JT: You're getting a signal that this is not in that interest (so the
document could be informational).
Melissa Shore (MS): I think this is Informational. It's here in tsvwg,
because RSVP expertise is here, although what worries me is it is a complex
architecture - there is a judgment call on complexity. I'm nervous on IPSsec
with different applications and mixing features in a short document - I want
many reviewers.
JP: The IETF is a community of volunteers. Where there is energy, we do
work, and help this to become a productive work.
MS: It's nearly impossible to stop bad work. It shouldn't be this easy to
kill good work.
MS: This merits a WG review and process time.
Tom Henderson (TH): I'd like to support this - it is an important problem
with my company (Boeing). RFCs help prevent peculiar solutions to problems.
AM: We can work on this problem in TSVWG, but we should ensure the NSIS WG
is fully aware of this work.

Jose Bart (JB): Scott Bradner said that pre-emption was a bad concept, in a
previous meeting.
FB: In this particular case, pre-emption is going to happen: There are
important critical (life-saving) cases.
JT: This work is relevant to a large customer (military).
AM: Hard pre-emption on a global inter-domain case is a hard problem. Can't
we do something at the link-layer to get some of this support? -
Implementing inter-domain pre-emption needs to address many problems. We
could do several sessions at the IETF on this.
?: Should we hold a BoF on pre-emption?
AM: No.  [I think I tried to say because it needs to be cross-area].
?: If we go this way, this will in future become an interoperable problem.
JP: RSVP already supports pre-emption.
AM: RSVP put pre-emption in where COPS used RSVP in a third-party, policy
managed manner - it was not generic.
Ted: What is the case against doing this?
JP: The ADs wanted this WG to open-up and do some thinking, we've done this:
The can is open now.
JT: Can we organise a WG meeting for the people who care and avoid the tsvwg
getting bogged down.
JP: I think it is important for these issues to go in front of the people in
the tsvwg.
JP: I'd like to call a hum on doing this work?
Hum, in favour.

-------

* Diffserv Basic Classes
http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx
t
Kok Ho Chan (KC)
Reviewers comments have been received - and there will be a new rev soon.
This document is close to completion - comments are requested from the WG.
Should this document be a BCP or INFO (WG or Individual)?

JP: Opinions please?
AM: The applications user community was asked for opinions on whether this
should become a BCP v. INFO and they will respond to the list.

JP: The IESG will ask us if the methods in the ID are a required way to do
these things: do we need to make this a BCP?
?: This draft is well written. Diffserv is being deployed. Can the carriers
using DS validate the classes, to make sure this makes sense.
FB: I've been to a variety of carriers and large enterprises to look at
this. The document was valuable to them - no one said they did not want the
document.
David Black: This is a well-written document, all my review comments have
been addressed. I don't know if the text is prescriptive or there may be
alternative ways of doing this.
?: I've been working with people who work with VoIP and knew nothing about
the networking aspects, and when shown this, they stopped asking stupid
questions...
JP: It certainly has informational value.
?: This is better published as informational, because it defines many
classes (a large set could cause confusions).
We got this feedback in a previous rev. The latest rev says you don't need
to support all the classes (you can aggregate several classes to a single
treatment).
Bruce Davie: Even if the text says so, people tend to jump straight to the
contents of a table. Publishing as INFO is a good warning to such people.
JP: I agree with Bruce, the warning text surrounding a table is often loss
when people cite a reference - this offers good guidance.
FB: We would like to prepare another rev.
JP: Is this next rev suitable for a WG document (as INFO)?
Humm - in favour of adopting this.

-------

* Quickstart
http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt

Sally Floyd.
This draft was previously presented to the WG and expired. A fair amount of
work has been done since then, and this is now brought back to tsvwg. Data
was presented showing NS behaviour. A case made for using an IP-option.

JT: Would this be a good mechanism that could also be tied to XCP - so that
this becomes a mode.
SF: Quickstart is not a congestion control measure - the use is occasional,
normally at the start of a session. Quickstart is good at figuring out what
to do in starting conditions. XCP has more parts (and more power).
JT: If I run Quickstart now, and then later XCP is deployed, we could use
the XCP mechanisms with these methods. I'd rather see a single TCP
mechanism, if this can be done.
SF: XCP offers much more info. If you just want a larger initial window, you
don't need this info.
?: What does change when you do Active Queue Management (AQM)? Oscillation,
worse?
SF: No, there are no complications - You only say yes, if the AQM say there
is no standing queue.
Mark Handley (MH): Could we have a worse than best effort case using
diffserv, that would have the same benefit?
SF: You'd need to know that this code-point was supported, when the host
sends.
MH: If you know this, it should serve the same purpose.
SF: Lower than best effort has differences.
?: Lower than best effort can end up with head-of-line blocking, that would
cause an impact even with the lower class.

Gorry Fairhurst (GF): We need to consider tunnels that hide lower layer
router behaviours (see earlier talks on VPNs), and it's hard to know what
happens in tunnels.
SF: There are some mechanisms described to help this, if there are problems,
tell us.
GF: Will do, would be useful to talk about on the list.

JT: Two questions: Is this a Work item for tsvwg? Is it for PS?
JT: I'm hesitant at going to PS with things that modify TCP. I am in favour
of this being Experimental.
MH: This is an IP change *AND* a transport change - it needs wider review.
JP: Is this good for a WG work item?
Hummm 
JP: In favour of proposing this to IESG as a WG Item.
JP: Is this good for a PS?
Small Hummm 
JP: In favour of adopting as a PS, so it seems more feasible for taking
forward for Experimental.

-------

* Transport Mobility
http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt

Wesley Eddy (WE)
This uses existing protocols for mobility using SIP, DNS, etc. Is there room
for another mobile IP protocol in the IETF?
Is this good for an Informational document?

JT: This does not cite any documents from the multi-6 WG, which did review
and document why this was not the way to this - because of the
shifting-sands problem with lower-layer decisions. This ID conflicts with
this.
WE: Yes, thanks for pointing this out.
TH: There are issues that need to change things at the transport layer -
this keeps coming up - this could be implementation specific, there's also
binding issues, do you need a general mechanism?
?: There is a (mobile-sctp) ID that describes the case where both end-points
are moving at the same time. You need a daemon to scan interfaces. The
Transport Layer is normally implemented in the Kernel.
?: Transport mobility is cheap to deploy.
JP: Several action items have been raised, please address these on on the
list.

-------

* XCP
http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt

Aaron Falk
This is a research project, it is not an intended WG item. There is ns code,
web pages, and a mailing list that are open to discuss this topic. XCP uses
explicit signaling from XCP routers to find congestion in the network. A
feedback loop returns the discovered bottleneck allocation. There is work on
fair-sharing with TCP; split connections; etc. This ID is to make the
community aware of current work, and invite contributions.

-------

* SCTP NAT Traversal
http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt

Qiaobing  Xie (QX)
Presentation reviewing guidelines and solutions for dealing with SCTP
association transversing NAT and similar middleboxes, and discussing
implications of traversing several NATs. Is this a good candidate for an
INFO document?

MS: If you are multi-homed - is a chunk sent on each address?
QX: No, only once.
MS: An inter-NAT protocol is really not a good idea.
QX: This is for future study.
MS: Just say, "don't do this" rather than "for future study".
JP: Please also send this to the behave WG (who know and are interested in
NATs) - you may receive good feedback.

-------

* RSVP for MPLS-TE
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt
Francois Le Faucheur (FLF)
Presentation describing admission control for flows within MPLS Traffic
Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering
(DS-TE) Tunnels. The ID discusses aggregation of RSVP end-to-end
reservations. Reviewed changes from -00 to -01, including use of a RSVP
proxy to aggregate ingress to the tunnel. Open issues were described and
will align with Hierarchical LSP work. The authors would like to progress
this work in TSVWG. We should send a note to MPLS WG to ensure visibility of
this work within TSVWG.

AM: This (tsvwg) is the place were MPLS and Transport meet. My opinion is
that it is right to work on this here. Some clarifications are needed, for
different cases, etc. A new rev will help this to be clearer, and then the
transport area can better understand the issue. TSVWG'ers please do ASK
questions about this.
?: I don't understand what RSVP-TE is, and how this relates to RSVP - Since
RSVP-TE is not a product of TSVWG.
JP: No time to answer in the tsvwg meeting...
?: What is the difference with TE and DS?
FLF: The core is an MPLS DS core. MPLS did not create a new QoS mechanism in
the data plane.
?: This is good work.


JP: Meeting closed at 17:30.





_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg