IETF
tsvwg
tsvwg@jabber.ietf.org
Friday, 29 July 2011< ^ >
Room Configuration

GMT+0
[12:14:30] Will Ivancic joins the room
[12:37:25] Will Ivancic leaves the room: Computer went to sleep
[12:56:47] jlcJohn joins the room
[13:00:22] jpc@jabber joins the room
[13:00:33] William Ivancic joins the room
[13:06:03] gorryf joins the room
[13:06:27] <gorryf> Is there anyone remote for today's TSVWG meeting?
[13:06:56] <jlcJohn> me...
[13:07:02] danwing joins the room
[13:07:40] <gorryf> OK - could you hear the audio?
[13:07:53] <gorryf> Meeting about to start...
[13:08:08] <jpc@jabber> yep, audio is OK
[13:09:34] wesley.m.eddy joins the room
[13:09:54] <wesley.m.eddy> on chairs' slides
[13:10:19] <wesley.m.eddy> agenda bashing (projector difficulty with slides)
[13:12:02] <jlcJohn> (Folks don't seem to get it -- presentations should be pdf unless it's on _your_ laptop and tested!)
[13:12:54] <gorryf> apologies... we're getting slides fixed.
[13:13:48] <wesley.m.eddy> it's a projector issue, apparently, the host's A/V is checking it
[13:22:37] <wesley.m.eddy> scott bradner: need to disclose IPR on the document whether std track or not
[13:22:51] <wesley.m.eddy> 2nd - depends on specific company, what "standard" means
[13:23:12] <wesley.m.eddy> some are explicit, this one is not
[13:24:50] <wesley.m.eddy> process is for WG to take IPR into account; discussion not necessary
[13:25:48] nestor.tiglao joins the room
[13:26:45] <wesley.m.eddy> bob briscoe - reviewed doc 2 times, unaware of IPR, technically he doesn't think much should apply since it's only giving guidance
[13:27:31] <wesley.m.eddy> harrington - looking to see if anything is normative, there seem to be some recommendations, he doesn't know what it being claimed or what IPR could apply to
[13:28:13] <wesley.m.eddy> on "TSVWG Accomplishments and Status"
[13:30:25] <wesley.m.eddy> bradner: you MUST only use SHOULD if there's a rational reason for not doing it
[13:30:44] <wesley.m.eddy> argues for MUST
[13:31:23] <wesley.m.eddy> harrington: up to chairs to call consensus and make editors work changes
[13:31:47] <wesley.m.eddy> gorry: will revisit on WG list
[13:32:00] <wesley.m.eddy> scott: s/SHOULD/MUST
[13:33:47] <wesley.m.eddy> randall: argues for MUST / MUST NOT
[13:33:52] <wesley.m.eddy> michael tuexen: same
[13:34:31] <wesley.m.eddy> scott: definition of SHOULD from 2119
[13:35:40] <wesley.m.eddy> briscoe: rationale needs to be there either way
[13:35:47] <wesley.m.eddy> scott: document speaks to that
[13:36:12] nestor.tiglao leaves the room
[13:36:56] <wesley.m.eddy> on "TSVWG Agenda"
[13:37:22] <wesley.m.eddy> nobody wants to bash
[13:37:51] <wesley.m.eddy> Michael doing draft-ietf-tsvwg-sctp-strrst-11.txt
[13:40:39] <wesley.m.eddy> version 12 will have everything addressed
[13:41:03] <wesley.m.eddy> gorry - if there are any comments on in-band signalling, make them quickly
[13:41:51] <wesley.m.eddy> next presentation, MULTI_TSPEC
[13:42:20] <wesley.m.eddy> on "scope of ID"
[13:43:02] <wesley.m.eddy> "RSVP vs. IntServ Object"
[13:45:10] <wesley.m.eddy> francois - 2 problems (things to do) carry multiple TSPECS, define how to process, this only defines alternative to the 1st, still left with processing
[13:46:09] <wesley.m.eddy> toerless eckert - why do you think this is an intserv thing
[13:46:40] <wesley.m.eddy> bruce: intserv deals with rules for tspecs
[13:47:56] <wesley.m.eddy> toerless: object is additional on top of primary tspec, these are addons
[13:48:13] <wesley.m.eddy> james: not proposing this but just presenting Lou's position
[13:48:17] nestor.tiglao joins the room
[13:48:26] <wesley.m.eddy> bradner: would there be a field to indicate what this is a multiple of?
[13:49:21] <wesley.m.eddy> james on "early example of RSVP object"
[13:51:48] <wesley.m.eddy> bruce davie - was association of tspec and preemption pri part of original?
[13:52:00] <wesley.m.eddy> james - no, but was going to try to drive it in, this takes care of it
[13:52:21] <wesley.m.eddy> bruce - seems like a good thing, lou's argument is good, cost is spending some brain cycles to figure out details
[13:52:49] <wesley.m.eddy> james - does this sound ok? worth pursuing?
[13:52:53] <wesley.m.eddy> does anyone have a problem?
[13:53:06] <wesley.m.eddy> (silence)
[13:53:12] jpc@jabber leaves the room
[13:53:14] <wesley.m.eddy> george karragianis
[13:54:17] <wesley.m.eddy> james explains processing
[13:54:50] <wesley.m.eddy> go to list - propose to move forward
[13:54:59] <wesley.m.eddy> on "newly fixed open issues"
[13:55:02] <wesley.m.eddy> on "new open issues"
[13:55:45] <wesley.m.eddy> revised draft expected after discussion on list (proposal for consideration by Taipei)
[13:56:39] <wesley.m.eddy> on Byte and Packet Congestion Notification
[13:57:05] <wesley.m.eddy> bob briscoe - adding clarity
[13:57:10] <wesley.m.eddy> gorry - getting ready for a WGLC
[13:57:18] <wesley.m.eddy> david black and fred baker agree to review
[13:57:50] <wesley.m.eddy> on ipr issue, there's 2119 language in this document, not appropriate for Informational
[13:58:42] <wesley.m.eddy> bradner: 2119 doesn't distinguish standards track or not, it depends on the ADs
[13:59:05] <wesley.m.eddy> harrington: current IESG prefers that you don't use 2119 in Informational
[14:00:26] <wesley.m.eddy> gorry: perhaps reconsider as BCP
[14:00:37] <wesley.m.eddy> scott: agrees, and then 2119 is reasonable
[14:00:46] <wesley.m.eddy> harrington: and is likely to go through without issue
[14:02:02] <wesley.m.eddy> on "status of sctp IDs"
[14:02:14] <wesley.m.eddy> draft-ietf-tsvwg-natsupp-01.txt
[14:02:24] <wesley.m.eddy> randall - we need to get this document done
[14:03:04] <wesley.m.eddy> please read document and comment
[14:03:32] <wesley.m.eddy> a thesis from one of michael's students has a few comments towards fixing it
[14:03:46] <wesley.m.eddy> implemented in bsd and its nat/fw code
[14:03:58] <wesley.m.eddy> michael - behavior of endpoints not completed
[14:04:51] <wesley.m.eddy> who's read it: 2 + authors (+ student) (and Michael points to 2 papers from australia - guys who don't come here)
[14:05:12] <wesley.m.eddy> on draft-ietf-tsvwg-sctp-udp-encaps-00.txt
[14:06:43] gorryf leaves the room
[14:07:40] <wesley.m.eddy> gorry: check who has read this?
[14:07:44] <wesley.m.eddy> please read
[14:08:21] <wesley.m.eddy> gorry: consider ecn considerations (if tunnel considerations apply)
[14:08:51] <wesley.m.eddy> randy: leave bits alone in sctp before you insert the udp header
[14:09:46] <wesley.m.eddy> moving to Will for Saratoga
[14:10:52] <wesley.m.eddy> (setting up laptop)
[14:12:05] <wesley.m.eddy> who's read it: 3
[14:12:35] gorryf joins the room
[14:14:30] <wesley.m.eddy> (trouble advancing slide)
[14:14:37] <wesley.m.eddy> on "private sensor networks"
[14:15:35] <wesley.m.eddy> scott bradner: why can't congestion be a problem?
[14:15:45] <wesley.m.eddy> only one thread - that's the key
[14:16:04] <wesley.m.eddy> tuexen - in former company, we built things assuming this, and then 10 years later things have changed
[14:16:13] <wesley.m.eddy> CC is hard to put in afterwards
[14:16:33] <wesley.m.eddy> will: we have looked at cc methods for this
[14:16:51] <wesley.m.eddy> scott: to follow up, in general IETF doesn't do protocols on stds track that won't work in the real world
[14:18:21] <wesley.m.eddy> (I noted it has tfrc as an option, there's a paper)
[14:18:37] <wesley.m.eddy> on "Saratoga's development"
[14:19:16] <wesley.m.eddy> on "Research led to new users"
[14:19:52] <wesley.m.eddy> on "Saratoga operation"
[14:20:48] <wesley.m.eddy> on "Features of Saratoga version 1"
[14:21:13] nestor.tiglao leaves the room
[14:21:14] nestor.tiglao joins the room
[14:21:46] <wesley.m.eddy> on "What Saratoga doesn't do"
[14:22:48] <wesley.m.eddy> on "Saratoga version 1 implementations"
[14:24:12] <wesley.m.eddy> on "Our approach to the IETF"
[14:25:35] <wesley.m.eddy> on "Saratoga frame types"
[14:27:39] <wesley.m.eddy> questions?
[14:27:48] <wesley.m.eddy> randall: mentions udp checksum
[14:28:01] <wesley.m.eddy> will: md5 over whole file
[14:28:21] <wesley.m.eddy> randall: stone's thesis talked about bogus checksums per packet
[14:28:29] <wesley.m.eddy> granularity of checksum seems weak
[14:30:24] <wesley.m.eddy> gorry: also games to play, since you don't have to actually check those chunks until you find out that something's wrong with the whole thing, then you can go back and process chunks
[14:30:28] <wesley.m.eddy> will agrees
[14:30:46] <wesley.m.eddy> giorgios karagianis - what kind of bundle convergence?
[14:30:53] <wesley.m.eddy> will: delay tolerant network protocol
[14:31:35] <wesley.m.eddy> will: highly asymmetric links
[14:31:59] <wesley.m.eddy> is bundle convergence related to beamforming?
[14:32:01] <wesley.m.eddy> no
[14:32:37] <wesley.m.eddy> gorry: back to call for comments: you should look at the UDP Guidelines RFC
[14:32:51] <wesley.m.eddy> currently slated individual for Experimental
[14:33:26] <wesley.m.eddy> Gorry: encourage some form of CC
[14:33:48] <wesley.m.eddy> onto port use
[14:35:57] <wesley.m.eddy> harrington: someone has to read it
[14:36:18] <wesley.m.eddy> gorry: please read, criticize, tell us whether we should do it
[14:37:06] <wesley.m.eddy> onto draft-tuexen-tsvwg-sctp-sack-immediately-06.txt
[14:43:20] <wesley.m.eddy> mirja: is there still a performance problem if you ack every packet
[14:43:31] <wesley.m.eddy> michael: depends on the size, could have 100 gaps
[14:43:44] <wesley.m.eddy> there have been studies, you can overload the receiver (modern cpu)
[14:44:20] <wesley.m.eddy> who's read it? 10
[14:44:25] <wesley.m.eddy> ish
[14:44:49] <wesley.m.eddy> would those people be willing to review?
[14:44:52] <wesley.m.eddy> 5ish
[14:45:29] <wesley.m.eddy> jana: quickly read it, second gorry's suggestion that mechanism is simple, but should indicate cases where this can be used (applicability statement)
[14:46:40] <wesley.m.eddy> gorry: hum for adoption
[14:46:44] <wesley.m.eddy> (reasonable hum)
[14:46:53] <wesley.m.eddy> hum for not-adoption
[14:46:57] <wesley.m.eddy> (no hums)
[14:47:14] <wesley.m.eddy> consensus to take on to-be-confirmed on-list
[14:49:24] <wesley.m.eddy> draft-stewart-tsvwg-stcpecn-01.txt
[14:50:36] <wesley.m.eddy> comments please
[14:53:22] <wesley.m.eddy> onto draft-tuexen-tsvwg-sctp-multipath-01.txt
[14:58:45] <wesley.m.eddy> gorry: should we have separate drafts? (multipath and failover)
[14:59:58] <wesley.m.eddy> ken carlberg: separate - testing and measurements
[15:00:15] <wesley.m.eddy> jana - clarification comment, multipath effort is divided among a few drafts
[15:00:19] <wesley.m.eddy> gorry - we'll come to that
[15:00:40] <wesley.m.eddy> jana - on the bottom draft, and I've said this before, it should progress independently
[15:01:17] <wesley.m.eddy> hum for support on draft-nishida-tsvwg-sctp-failover
[15:01:20] <wesley.m.eddy> (strong hum)
[15:01:24] <wesley.m.eddy> hum for not support
[15:01:27] <wesley.m.eddy> (silence)
[15:01:40] <wesley.m.eddy> to-be-confirmed on list
[15:03:48] <wesley.m.eddy> jana - points out that the multipath work has been implemented since 2006 (not built on mptcp), it has been deployed in a number of places, but not turned on by default
[15:04:25] <wesley.m.eddy> michael - completely right, cmt is in there for years, question is what combination of stuff you need (non-renegable SACKs, etc)
[15:04:49] <wesley.m.eddy> CMT was not brought to IETF because coupled congestion control was missing; now we have it from mptcp
[15:05:30] <wesley.m.eddy> gorry - articulated here but not on WG, should do so
[15:05:50] <wesley.m.eddy> gorry - should WG work on multipath problem space (TOPIC)?
[15:05:55] <wesley.m.eddy> (decent hum)
[15:06:08] <wesley.m.eddy> more discussion needed, shouldn't be working on it?
[15:06:11] <wesley.m.eddy> (silence)
[15:06:34] <wesley.m.eddy> intention to proceed, subject to knowing exactly what work items are
[15:07:31] <wesley.m.eddy> gorry - asks about background in pcn
[15:08:10] <wesley.m.eddy> an item that has to be satisfied by pcn is a signaling protocol to transfer from egress node to ingress node and must maintain aggregates
[15:09:31] <wesley.m.eddy> (we're on georgios presentation "generic aggregation of resource reservation protocol (rsvp) for IPv4 and IPv6 reservation over PCN domains")
[15:09:41] <wesley.m.eddy> on "outline"
[15:10:06] <wesley.m.eddy> on "motivation (1)"
[15:10:49] <wesley.m.eddy> on "motivation (2)"
[15:11:23] <wesley.m.eddy> on "motivation (3)"
[15:12:39] <wesley.m.eddy> on "motivation (4)"
[15:16:07] <wesley.m.eddy> on "main augmentations on generic aggregated RSVP (2)"
[15:18:10] <wesley.m.eddy> on "augmentations to PCN SM and CL edge behavior drafts (1)"
[15:19:17] <wesley.m.eddy> on "augmentations .. (2)"
[15:19:55] <wesley.m.eddy> on "next steps"
[15:20:16] <wesley.m.eddy> who's read this draft: 3
[15:20:30] <wesley.m.eddy> comments on usefulness and rsvp-issues that this WG could help with?
[15:21:03] <wesley.m.eddy> ken carlberg: a little of both - satisfies PCN need, and should go forward and last-call in PCN with subsequent (not parallel) with TSVWG
[15:21:45] <wesley.m.eddy> james polk: provided some corrections, incorporated quickly, PCN or TSVWG ... wanna arm-wrestle
[15:21:51] <wesley.m.eddy> scott: to give it away?
[15:21:58] <wesley.m.eddy> james: 60/40 TSVWG
[15:22:56] <wesley.m.eddy> scott: in any case, it's the RSVP directorate who has to look at it ... TSVWG will just send to them; PCN could do that, it should be last called here, whether it's done sequentially or in parallel doesn' t matter
[15:23:08] <wesley.m.eddy> harrington: if it was done in PCN, it would still go through RSVP directorate, and probably last call here
[15:23:51] <wesley.m.eddy> david: milestone is already on PCN charter, would be happy to transfer it
[15:24:28] <wesley.m.eddy> will talk to ADs to figure out where to place tihs piece of work
[15:24:32] <wesley.m.eddy> going to James
[15:25:06] <wesley.m.eddy> Combo RSVP App-ID and Traffic Class preso
[15:25:13] nestor.tiglao leaves the room
[15:25:33] <wesley.m.eddy> hummed for adoption in beijing ... didn't make a call
[15:27:31] <wesley.m.eddy> on "what this draft is about"
[15:28:43] jpc@jabber joins the room
[15:32:05] <wesley.m.eddy> harrington: question on proprietary delimiter - are you standardizing behavior
[15:32:08] <wesley.m.eddy> james: yes
[15:32:18] <wesley.m.eddy> recommending to take what you understand, and do a match
[15:32:26] <wesley.m.eddy> order doesn't matter
[15:32:34] <wesley.m.eddy> ken carlberg: is there a registry
[15:32:38] <wesley.m.eddy> james: getting to that
[15:32:45] <wesley.m.eddy> on "individual component parts"
[15:38:40] gorryf leaves the room
[15:38:43] <wesley.m.eddy> meeting adjourned
[15:38:45] jlcJohn leaves the room
[15:38:46] wesley.m.eddy leaves the room
[15:38:49] jpc@jabber leaves the room
[15:39:37] danwing leaves the room
[15:40:48] William Ivancic leaves the room
[15:42:45] danwing joins the room
[15:43:14] danwing leaves the room
[15:59:19] nestor.tiglao joins the room
[16:02:55] nestor.tiglao leaves the room
[16:59:32] danwing joins the room
[17:02:38] wivancic joins the room
[17:03:30] danwing leaves the room
[17:03:46] danwing joins the room
[17:09:54] danwing leaves the room
[18:08:22] wivancic leaves the room
[18:09:53] wivancic joins the room
[18:10:59] wivancic leaves the room