[Tsvwg] Minutes of TSVWG at IETF 56

[Allison Mankin <[e-mail]>]

These are due today it seems, so send corrections to the list, where
our archives can serve as the record.  Thanks to Spencer for the 
note-taking.

Minutes taken by Spencer Dawkins

==================================
Transport Area Working Group TSVWG
==================================

Allison Mankin and Jon Peterson

Scott has been replaced by Jon as AD but will still be active

Kireeti - Status of RSVP change document
	RSVP has become very popular, people outside IETF want to change it
	this causes difficulties for interoperation - how do we prevent breaking RSVP?
		recent code points RFC from completely outside IETF with a lot of pushback
	give RSVP IANA considerations that it's never had before
		previous considerations draft had expired
	give three code points (normal use, experimental use, first-come-first-served)
		really need a "standards action" code point, too
	also need PS RFC to initiate behavior changes
	is this important?

	Andy Malis: this is absolutely needed - 
		IANA is working with no guidelines whatesoever
		even first-come-first-served space is broken
		Bob Braden is now the gatekeeper and things are confusing
	
	Bob Braden has suggested name-based sand boxes - not much reaction - do people care?
	Allison: IESG suggested names not reflect owners for maintainability

	Philip Matthews: IS-IS has the same issues 
		and is dealing with them in the same way
		Split between class numbers and C-types?
	
	will be discussed on TSVWG mailing list

Jukka Manner - Localized RSVP (LRSVP)
	end-to-end QoS is rarely available
	backbones fast and reliable
	access networks are bottleneck congestion points
	using a small enhancement to RSVP that can coexist with RSVP
	Local Indication and Expedited Refresh bits allow coexistence
	Open issues - addressing, asymmetric routing, interworking with end-to-end RSVP, security

	Steve Casner: each end signals its own access network?
	A: end-to-end is preferable, this is fall-back

	Steve Silverman: is "local" on a LAN?
	A: "local" access network

	Tom Hiller: 3GPP does things almost identical to this
		not documented in RFCs because never leaves walled garden

John Bennett - IP measurement OAM problem problem statement

	measure ping, traceroute, etc.
	can't do this because ot ICMP blocking, flow-specific routes, hop-by-hop vs. end-to-end
	want to measure increasingly specific things (take HTTP redirect into account, etc)
	can't figure out which hop is the problem
	need a new protocol that can be processed in fast path - no control
	"polite" protocol
	passes through firewalls, NATs, etc.
	"IP Measurement Protocol" - IPMP Echo, IPMP Information Request
		proposed by Andrew McGregor a couple of years ago
	bennett-00 changes adds redirection, port numbers, TLVs
	mcgregor-00 and bennet-01 also make changes to previous proposal

	Peter Neuman - would like to measure downstream with standardized protocol
	Q: also have a draft we'd like to be considered
	A: looking at general level of interest first	

Sally Floyd - draft-floyd-tcp-highspeed-02.txt
	Quickstart revision is also out for comments
	adding a new response function for TCPs on links with very low error rates
	revision adds discussion of TCP with multiple connections
		Scalable TCP from Tom Kelly
	Adds a section on choosing parameters
	Adds discussion on P-MTU, window scaling, etc.
	Shows simulation results from Evandro de Souza
	in a drop-tail queue? would work better with small P
	Need feedback from community before Experimental RFC
	Limited Slowstart proposal is also related
	Other changes? Higher dupack threshold, etc.
	TCP Quickstart isn't ready to be Experimental RFC - needs more research
	
	Allison: what is the complexity?
	A: maintain a table instead of always cutting in half
	Eric Nordmark: current reference implementation uses scaled math
		cutting in half is easy, cutting by 22.9 percent is harder
	A: could approximate by shifting
	Matt Mathis: uses integer arithmetic
	Reiner: why don't smaller congestion windows get to use this?
	A: need to pick targets for response functions for divergence from standard TCP
		motivation for picking is that TCP is successful now, so small changes
	Matt Mathis: Fairness on the Internet is because of standard response function
		can't let everybody dork with their response function - no fairness
	Q: Not good at translating from drop rates to technologies
	A: starting at 10**-6 packet loss rates, High Speed TCP seems to make a big difference
	Mike from Digital Fountain: have you tried parallel sessions of HSTCP?
	A: yes, pointed to from web page, so far it looks fine
		congestion network would be better off if you're using HSTCP
	Joe Touch: use RSVP for SYN, because we're in slow path anyway
	A: maybe, but not yet
	Joe Touch: point solution for 10-gig Ethernet? more dynamic than you're thinking about
	A: can you talk about this on the list?

        hum to adopt as WG item 

Ethan Blanton - draft-blanton-dsack-use-02.txt

	building from Atlanta discussion
	solved real loss during recovery
	what do we do now?

	Randall Stewart: perfectly safe, move it forward
	hum to adopt as WG item

Ethan Blanton draft-blanton-tcp-reordering-00.txt

	can we recover our congestion window?
	need to prevent massive burst at window reversion time
	need to prevent spurious fast retransmits
	presenting four schemes of increasing complexity
	most conservative scheme is most complexity
	need more data, would like to hear alternative schemes
	spurious RTOs is explicitly out of scope
	Matt Mathis: there are lots of heuristics hidden in real TCPs that will cloud your results
	Mark Allman: should this sort of algorithm be Experimental? They're conservative
	Allison: some RFCs are really experiments, some are really for immediate use
	Sally: Experimental after one real implementation?
	Allison: We use "experimental" to mean several different things
	Sally: Texas A&M proposal could be added to this work
	
Mark Allman - draft-allman-tcp-early-rexmt-00.txt

	No oppositions based on the list traffic, right?
	splitting this work out from Limited Transmit
	less resistent to reordering, but ...
	Spencer: worse cases are bad in macro sense but effect on user may justify this

Sally Floyd - Proposal for newreno standardization
	Newreno is widely deployed and is still experimental - move it forward?
	please identify any major fixes this would require (but not other ideas/changes)

Reiner Ludwig - Redundant data in TCP?
	TCP-friendly with quotas on good and bad bytes?
	please feed back to the mailing list

Randall Stewart - draft-stewart-tsvwg-prsctp-03.txt

	Phil Cochran - SCTP bakeoff at UDelaware June 1-8 (unofficial)
	PR-SCTP has been around for a while - the first service designed
        by the spec  provides "timed reliability"
	"abandon" stale chunks of data
	still make congestion window (downward) adjustments
	only enabled if both sides understand it!
	three independent implementations, all interop tested
	seven additional implementations coming

	Mark Allman: making it easier to throw useless data into the network?
		should be considered the way we're considering Reiner's proposal
	Randall: will construct a scenario on the list

	David Black: this is the opposite of Reiner's proposal
	Randall: better than I could have said it

	Allison: noticed spec made possible to change the lifetime after it was set,
         suggests interesting race conditions, API complexity in name of flexibility/power...
	Phil: lots of good issues...
		agree that if you can change lifetime values, this creates race conditions
		larger question is about creating lots of new services
		two parts of proposals - on the wire part is what we need to standardize
			policy is internal to a node
	Randall: realistic, can't change this in internal implementations today
	
	Mark: more motivation on the list?
	Randall: unreliable stream didn't simplify anything (per previous connectathon)
	Mark: couldn't you simplify per-stream, not just per-packet?
	Phil: good points for application writers, but these are service definition API issues
	Randall - I could do what you're saying in the current implementation
	David Black: setting timeouts is valuable in some scenario

        Chairs: review to be continued on list.


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