Last Modified: 2004-06-08
The tsvwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion.
The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose.
| Done | Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard | |
| Done | Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard | |
| Done | Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard | |
| Done | Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard. | |
| Done | submit revised ID for ECN to IESG for consideration as a proposed standard | |
| Done | submit ID on UDP-lite to IESG for consideration as a proposed standard | |
| Done | TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard | |
| Done | Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard | |
| Mar 04 | Submit early retransmission to IESG for consideration as Experimental | |
| Mar 04 | Submit SCTP Implementer's Guide to IESG for consideration as an Informational RFC | |
| Apr 04 | Submit Eifel response to IESG for consideration as a Proposed Standard | |
| Jun 04 | ECN Nonce procedure submitted to IESG for consideration as Proposed Standard | |
| Sep 04 | Submit ID for SCTP API for consideration as an Informational RFC | |
| Sep 09 | TCP-Friendly Variable Rate Control unicast congestion control submitted to IESG for consideration as a Proposed Standard |
| RFC | Status | Title |
|---|---|---|
| RFC2861 | E | TCP Congestion Window Validation |
| RFC2883 | PS | An Extension to the Selective Acknowledgement (SACK) Option for TCP |
| RFC2988 | PS | Computing TCP's Retransmission Timer |
| RFC3042 | PS | Enhancing TCP's Loss Recovery Using Limited Transmit |
| RFC3168 | PS | The Addition of Explicit Congestion Notification (ECN) to IP |
| RFC3309 | PS | Stream Control Transmission Protocol (SCTP) Checksum Change |
| RFC3390 | PS | Increasing TCP's Initial Window |
| RFC3436 | PS | Transport Layer Security over Stream Control Transmission Protocol |
| RFC3448 | PS | TCP Friendly Rate Control (TFRC):Protocol Specification |
| RFC3517 | PS | A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP |
| RFC3522 | E | The Eifel Detection Algorithm for TCP |
| RFC3649 | E | HighSpeed TCP for Large Congestion Windows |
| RFC3708 | E | Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions |
| RFC3782 | Standard | The NewReno Modification to TCP's Fast Recovery Algorithm |
| RFC3742 | E | Limited Slow-Start for TCP with Large Congestion Windows |
| RFC3758 | Standard | SCTP Partial Reliability Extension |
| RFC3828 | Standard | The UDP-Lite Protocol |
|
Transport Working Group (TSVWG)
for IETF 60 Matt Zekauskas offer to take "fair and balanced" notes. This offer was accepted and the following notes are the result. Decisions are recorded, as well as a fair amount of the detailed discussion. Colin Perkins and AVT plea: Colin is co-chair with Magnus Westerlund. a couple of drafts than bigger scope than AVT WG. MPLS Voice Header Compression work in AVT requirements, experiment could expand into a bunch of compression things over MPLS. please look if you're interested in header compression &/or MPLS and send comments! RTP profile for TFRC experiment w/in existing framework. not replacing DCCP. since tsv developed tfrc, would like thoughts. feedback. ================================================================= Mathis tcp estats mib web100 rationale... when there is a problem just ask TCP "it's the guilty party" problem is the fundamental artifact of hourglass. need debugging in protocol since hourglass hides protocol broken leading edge network looks like last years commercial network web100: six groups of instruments stuff you negotiated. 1323 timestamps... traffic & throughput: measuring performane of app (elapsed seqno space) things using from network (# transmitted packets) abstract cong & triage: signals driving cong. windwo. triage like split timer at racetrack... why tcpoutput stops sending data time in 3 bins. rcvr window limited, cong window limited, ran out of sender data. to first order points figer to right subsystem. path properties. early hope, mirror some IPPM metrics rtt, losses, reordering sender buffering: what sender process doing receiver window, signals sent, buffering: what receiver process doing 135 instruments in 8 tables. --- historically, a pair of dueling drafts: 2012 - tcp mib draft. has been updated to support v6. original versions of that included add'l instrumentation for tcp. "our stuff" went into estats mib. 2012bis... went back to just IPv6 estats... everything else. --- baking for a while. would probalby let bake forever. because find new things to instrument every once in a while. (gee wished I had found that) prior addition to MIB is a yr ago. so baking long enough. time to get closure. implementation rumors from at least 3 teams. asked questions by people that seem like writing code. helped tighten text. about 2 dozen comments that have been closed. outstanding issues: 9 items. mostly smi ambiguity issues. tcp geek not SMI. Ready a MIB Doctor review. partitioning into tables: done to facilitate reducing memory footprint. MIB takes as much memory as process to do it an a straightforward way. easier to swollow if in groups that could turn on & off. no good insigntn http://www.web100.org/mib/ Joe Touch: mib contain anything like bit that says "back off if process load gets too high". most of objs updated as side-effect of proto processing. add'l stuff to turn off almost as expensive. more worried about mem footprint than cycles. joe t: useful to have cycle processing impact. whether switch makes sense lingering questions about 2012 stuff accurately reflected in document. other questions? casner: side comment... in AVT yesterday, one of comments on first slide was address perf in protocol or won't be used. alan clark made same comment yesterday. should have performance considerations section in protocol document. not sure how feasable. but is a concern that should be applied. broader than protocols in AVT. mm: agree strongly. also inverse needed... token in paragraph, if see event must instrument and expose ======================================================================== Francois LeFaucheur draft-lefaucheur-rsvp-dste-00.txt background... 3175 aggregation of rsvp for reservatoins. because rsvp is receiver driven, most of intelligence in deaggregator. looking at 3175 over mpls-te tunnels. * smarts to head-end * some modification of procedures. targeted app example. mpls core, mplste or diffserv aware te voip trunc gateways. either PSTN or Mobile flows from gw to gw. some options described. per-call reservations or preaggregated reservations. open items: * optional RSVP proxy behavior on head-end. (head-end term path and gen resv, etc.) * handling TTL MPLS penultimate hop popping is typical. make sure do right ttl processing, path processing do same thing as Heirarchical LSP (mpls inside MPLS?) * future: dynamic discovery/establishment of TE tunnels needed? (other stuff in 3175) but don't think it's necessary want to progress document here in TSVWG. jon: any discussion. kwok ho-chan. when add CAC to LER at head end... what do you consider scaling factor. when add ... for tunnel, state? when you handle 300000 calls, how happen. question is what about scalability at head-end. that box maintains per-conn state on call. * these reservatoins do not have to be per-call. could be gw do pre-aggregated reservation. may reduce # of resv by 3 orders of magnitude. (biggest answer) * many of edge boxes, so more of them mean fewer total. figure boxes can handle 1000's or 10000's of reservations. (but more tunnels) implementation and design tradeoffs. ruediger geib. didn't read draft, but do you support both services of intserv, or just controlled or gtd rate. not in spec. spec says, how to support rue: but then have to implement admission control. so can't give such an answer. how solve mapping problem between intserv svce classes and diffserv classes see intserv or diffserv integration draft. q: 2997 (intserv over diffserv) the ISL(?) working group looked at the mapping problem some time ago. fransua and I had discussions about this. if precise guarantees...think know how to do guaranteed service t-spec onto tunnel. pix with what sorta tunnel to map guarnateed service q allison: what's the difference between this and just tunelling rsvp. (distinguish from tunnel rsvp) looked hard at that doc when specified 3175. allison: but spec doesn't do much more. that spec is just 3175 and MPLSte tunnels. bruce davie: looked at doc when 3175 and looked again writing this one. tried to figure out all details at engress and egress when processing rsvp elements. not everything in tunnel rfc some mapping steps to MPLS TE tunnel aren't there. tunnel rfc spcs 3 different types of tunnels. this is one of those 3 thypes of tunnel. when tunnel is MPLS tunnel. allison - is natural for WG. thins to configure fixing... but natural. hum as acceptance for wg vs. individual...how many people, work into reviewing document pretty strong hum if support take into tsvwg loud hummer close. prety strong take that into consideration. ===================== james polk. RSVP bw reduction in tsvwg polk-tsvwg-rsvp-aggregate-bw-reduction-00 rsvp sets up tunnels for many things... 3175 says how set up 2205 means to preempt flows. situation where indiv flow or aggregate that's congested...entire flow or aggregate would have to be torn down and restablished at some value where endpoints don't know. * add something to reserr message to say what bw is available? (rather than tear down) instead of reserr-preempt, reser-reduce open issue: w/in rsvp... reduction goes to end point, sip would tear down. better way, change 2205... res tear message go out to router 5 w/same reduction bw elt. (see pix) open issue: what if router says reduction message, but doesn't see any action w/in some time? open: how much should text talk about indivudual flows? (should work, but draft is just aggregates ruediger: talk about reservations. send ECN to reduce traffic. not related unless measure. Aggregate -> SIP silent periods... multiplex never as big as reservation. assuming reservations, not real traffic. do not measure to determine if have 20k. talking about reservations.. never look at actual traffic. idea of what could be there. not sure if need all this. bruce davie: assumption behind draft... parameter based admission ctl vs. measurement based adm control. ruediger: in draft mention ECN. puzzled, didn't see relation. no not in draft. >> take offline. ruediger: doesn't say how B chooses flow. "local policy". person from audience nakota/NTT: in this model, router 9... how does r9 select target aggregate to reduce. right now not specified. : in this picture 2 pipes. no alternatives. but lots of pipes between 9 and 10. not defined. : if router 9 distributes info, some computation issues. francois: aggregate to pick not something to standardize. no collab across routers to pick same one. don't have to standardize. doesn't mean you can't do something smalrt. speaker: send email with suggestions... put in as non-normative stuff. david raskin? xxx david from lockheed martin: error goes to R10. decides to tear flow to router 8. reserve tear starts at r9. right now says don't send immediately would be interp by r5/6 to tear down entire reservation. david raskin? xxx: don't know that same flow will be torn down by both sides, depend on SIP want to fix that. want to see diagram of flows, and error cases. subha dresh. (cisco) one of coathors... (female, indian?) to answer david raskin's question. to to synch agg & deagg. reason it's open. want to synch res in router 5 & 6. objective is not for aggregate itself, but to inform intermediate routers. still open issue, so would discuss how to casner: use cases for this. how often operate system in scenario where where you would hit congestion sit. most engineered so never get near this with reserved bw. right. most won't. but know a very large US govt network that doesn't have adequate bw everywhere. going into aggregates... 5 different priorities for communications. so it's not 1-2, but 5. chose in times of emergecny. will make clear in document. ============================================================== real time ECN update: draft-babiarz-tsvwg-rtecn-01.txt jozef babiarz <look at differences draft> routers measure per-flow; set ECN can be deployed incrementally * explore alternative ECN semantics. 3168 apps that require two levels of congestion. looking for new semantics to detec this. q (jon): changed in this one from last at high level? - restructured -reworded, semantics and usage want to align wording to 3168. would like to request for comments, and further discussion on the usage of ECN concept for controlling real-time UDP flows. more comments and discussion on list sally: talked w/authors on mon. interactoin w/reg ecn. 3 suggestions. 1. words. current doc says that ECN for TCP, not case, for anything 2. if packets go thru ECN enabled router that understands DSCP, and then one that doesn't understand DSCP. odd things can happen, needs to be dealt with 3. because don't have nonce anymore... nonce that's erased when cong. indication is set. fundimental with more than 1 bit. need to think about routers cheating, and the costs. and if end nodes cheat. meachnims to protect. q: interested in this approach. proposed some meas approach some meetings ago. one issue: how supply redundant routes. if some breakdown. if route fixed may work. if route changes... usu mechanism to use alt. route current proposal only talks about mechanism. could make suggestions on what apps should do ruediger: didn't follow discussion, and didn't read doc. but like the idea. not sure about soln. but like idea of adding ECN to rt apps is good. get official support. allison: same comments from minutes last time. think that not make WG doc... want to have people follow up on ... don't know if it takes making it a WG doc to have follow up. not sure if people think this idea is solid enough that it is a WG doc, or enough concerns that... don't want to have same discussion each time. not any negativity, want progress. sally: not trying to argue that it should not be wg doc. issues into record. and think progress is being made. ruediger: like issues, not document in particular. allison: right thing to do is thing done with ds basic classes. volunteers to do thorough review to pursue. willing to do thorough active review with him. ruediger geib. working on QoS. like that it takes idee of end system adm control, not expert in ecn or dscp. would like to use it. ted f makes comment -- he's a reviewer too :). will do a rev. will put on ML. elicit reviews and comments. (say what done when put on ML). ===================================================================== sumitha bhandarkar, TAMU. LTCP idea. here or in tcpm? addressing suboptimal perf of tcp in few gb/s, or several hundred ??? increase 1/RTT conservative. reducing by 1/2 is also aggressive. stripe data across several parallel TCP connections. some research in making TPC emulate several connections but # of connections is not easy then it's a static alloc. prefer that # of virt connections change dpeending on network conditions. that's what draft proposes. layering approach - a number of virt conn over real one. general framework design option to show effectiveness of approach, not as final soln. strawman. like to hear w/people. ready for standardization... jon: since time pressure.... discussion of placement soon! want experimental RFC to aid broader eval. jon: placement discussion mark, ted? mallman, as participant: option 3. not ready for either. sally: other things in this space. HSTCP experimental. FAST discussed here. tom kelly's STCP. whatever decision is made, should be same as others. all HSTCP should go all here or all tcpm. bigger than just this consideration. allison: one intuition is that any tcp that handles this space should all go together. another: tcp that changes tcp friendly discussion. and that question might not go with TCPM. tcp that maintain tcp friendlyness... if change friendly question, here... if don't change firendly go to tcpm. speaker: design proposed in ID is AIMD. joe touch: hadn't expected things to come up may be AIMD. are changing parameters, changing cong ctl broader issue... same as Reset discussion in tcpm. needs to be agreeement in this group before handoff. other issue, well put: ready for this decision or not. useful for round of feedback before make deicsion. for now, put off. mark handley: anything that changes cc dynamcis, have implications that are broader than TCP. so then want a wider range of people, discussed here or IRTF (although no forum so a vote for mising cc research group. allison: don't know answer yet. speaker: send us comments, please! =========================================================================== SCTP bakeoff report & status. 7th SCTP interop in U muenster. list of stuff tested. tested two bonus drafs. ecn nonce, socket api 11 impl, 9 orgs. all but one got over 200 pts. host-name-addr parameter not tested, no one impl. [[packet drop draft]] socket API tested -- passing code to each other. only 2 minor clarifications for impl guide: parameter handling, t-bit should be "tag reflected bit". cover all major OSes. - ---- Authenticated chunks for SCTP. draft-tuexen-sctp-auth-chunk-01 no progress. reason... need to add something. [[???]] make sure that when receive a chunk is with peer started association with. doesn't rely on addip. - -- differences now: per-endpoint PAIR shared secret change chunk types of what authenticate (not restricted to addip) <were more> --- diffie-hellman to xchg shared secret two random numbers on secret. because p2p model. message flow (for preshared secret) - don't need to use try to push computational expense into userland. questions/remarks/suggestions/ qiaobing xie motorola q: quenming(?) - terminology for endpoins and associations confusing. per pair of endpoints... then only one association. yes, right. but if endpoints, can have association. clear, then have another one. [serially]. so to avoid replay from earlier associations. q: comment is on terminology [[I didn't catch the exact suggestion]] no problem with naming. please send to list. ==================================================================== localized RSVP draft-manner-lrsvp-03.txt jukka.manner www.cs.helsinki.fi/u/jmanner/lrsvp_ietf60.pdf reservations where both endpoints don't talk rsvp. (see slides) two unused bits in session object, w/2 new message types. proxy at edge of RSVP network. goes from rsvp enabled end-host to proxy, and that goes backward toward end host to set stuff up. spec and operation stable since -01. have some other things... should we do as experimental carsten b(?): there are about 50 internet drafts that require friend in network. they should talk to each other. some using mobile ip home agent. some have rsvp proxy. are other ideas. good idea to find out different ways of finding friend, app scenarios, anything in common. looks to me like need this functionality. lots 'o functionality. first question to you how find this guy (local rsvp proxy) a: basic case, don't need to. routing infra routs packets will eventually find it. don't need to spec. proxy thing... easy to talk about proxy than enhnaced rsvp router. prefer to call this, because more than just standard bruce davie: have only skimmed. looks like something that people have wanted for a long time. repeatedly for last 5 yrs ago. rsvp proxy draft hung around but never made it. done simmilar things in cable environment high-order bit: something needed. keep this draft around, and see if can't progress to experimental. melinda shore: definitely a need for this kind of thing. but not crazy about sending msg in fwd dir to proxy. location problem add'l messages if change rsvp anyway, just start installing resv in fwd direction. really belongs in end sys... but need for rsvp. not add messages, not add new mechanism. do downstream reservations in fwd direction. a: thing in path... up doesn't this do same thing melinda: specifically to sending req to proxy to send path message. but that chagnes behavior a little too much. path to set up stuff in reverse direction mel: yep, but changing... previous draft, field to say when downstream could be placed, and when not. idea here... something simpler direct. mel: but not simple. subha dresh. (cisco) ?, indianwoman: second what melinda & bruce says. see need for solution, but not crazy about this one. since adding flags... put into rsvp message, say respond back with path message location problem... reciever proxy from many years back. prefer that kind of solution. idea that had, keep standard rsvp messaging as intact as possible. path in data dir, res in other. don't change any of that. get some entity to send path message toward receiver. change as little as possible of rsvp. francois: suggestion - add same reaction as others. not nice to send directed message to guy. but path to resv in fwd dir doesn't work if routing is asymmetric. something in path mthd travels hop by hop, triggers proxy in revers direction. (piggyback trigger in msg) pix was bad. same routing for path request. which IP addr in destination to be able to route it. initial idea...don't need to know IP addr of proxy. routed as path message. f: at least save extra message. jon: good cause for more ML discussion. - ---------------------------------------------------------- allison: go straight to diffserv basic classes discussion. last time asked for reviewers. work with them first. reviewers will come up. one on list (Alan O'Neill, Flarion), but he's represented by Scott Corson, from Flarion. Others: Brian Carpenter (bc), David Black (dlb) after that... ? will be discusser of document, and changes in response to reviews... then discusison of doc. ====== dlb: worked on ds, co-author of core rfcs. seen it earlier. liked it a lot. having reviewed good and necessary thing ds as toolkit. parts build classifiers conditionalrs and create behavoirs. this draft is a project plan. build treehouse, deck out back. long overdue addition to docs. nice job weaving it together. those in ds always had this idea. comments on draft biggest, high-level structure and view. how go about figuring out how traffic decomposes into classes in draft. if new proto, how figure out which class? summaries and structureal work. UMTS classes in a few places, bring together. good draft, valuable doc. too good... makes it look like we knew what we were doing. real history not that straight a path. alliso: recommended changes? have some. talked to authors. generally agreable. will send review to ML. ======== bc chair of former diffserv WG. coauthors. tend to look at all ds drafts this doc does "least damage to ds arch". a real compliment. very good. high level comments (not much to criticise in details): some people, ops, ISPs that haven't read arch rfc, or books, or ... might assume if read this, that MUST implement all these classes. know warnings in text, but must be really really really clear. that this is menu, pick off items you like. suggested text to authors to emphasize. another thing: lots of MUSTs in the document. most of them should be SHOULDs. one or two that should be MUSTs (unpleasant things happen). emphasize that there are options, not implement everything. example of MUST: service MUST be engineered so EF flows have enough bw to guarnatee delivery (is defn of EF, after all). useful, particulary for IPS that use O'reilly books to run netwroks. will gladly review successive versions. reudiger: brief comment. t-systems. big bbone. agree with brian... too many MUSTs. also mentions multiple EF queues, don't understand concept. EF draft, one queue for EF, now multiple ones. not sure about impl, and... bc: AF draft refers to 4 clasess. could be 1 or 7. know of no reasons why not multiple EFs. 3 mb and 23 mb. (voip and video). surprised that EF rfc that is written in language to interpret as exactly one class bruce davie: co-author of ef rfc. I haven't read it for a while...pretty sure multiple EF queues. discussion at time. impl mostly as Priority queue... but could impl as WFQ. which is why two go-rounds on EF RFC. absolutely allows multple ones. bc: mistake in DS wg... one cp for EF and 4 for AF. confusing people ever since. chris / booze allen. mention of ITU 1541.Y spec. matching for classes between documents? how do two come together, in conflict. (ECN thing speaker)jozef babiarz a co-author. still have mapping of service classes in BCP to Y1541. could put in back as informational. in BCP only specify characteristic behaviors. on EF issue, currently BCP, specdify that add'l EF use WFQ for clarity. allison: reviewers a q. thinking of how work in arch of ds. but it directs applications. telephony apps MUST or SHOULD use a different class. bc: would you direct application user..vs nw implmentor. get app reviewers. bc: interesting q. should app designer figure out class. from what I know... under illusion that one EF and 4AF, choose 1 and hope that nw does right thing. mmusic right place? say SIP... case for cross-area review. different tsv department. for me make sense, not sure that video wouldn't use another ef class. allison review from network arch level review from apps arch level not saying should do app classification, but is arch of app in document well devised. different review. dlb: looked at this from pov of nw admin. classes for signalling traffic. multimedia, low-latency app, or pieces of nw equip. view that are admin useful distinctions in addition to traffic characteristics. think that's useful. (and in draft) ====== kwok ho-chan. draft-baker-diffserv-basic-classes-03 issues in -03 draft. changes from -02. (see slides) will do must/should review did some restructuring based on reviews. next steps: will have open issues list, capturing dlb, bc, and other comments will rev draft ASAP. want feel from WG, maturity, and schedule for completion jon: clearly planning rev right now... take wg consensus to get that underway first, address initial comments. also other review (apps) that want to solicity. so: - take that step first - get version out there - get more review w/o asking how progress here. but progressing here progressively liklier. allisoN: operational security document in operations... gives prescriptions for securing network, routers. ended up being informational with MUST/SHOULD. w/a lot foa pplicability stmts. useful info. long time to have enough review and consensus. this doc has parallels. enough communities and stakeholders need review. not clear about std status, because so many stakeholders. so many places for it to be a std might miss fact that 2 yrs from now discover we missed something very important. but still a lot of prescriptive force. may find self on other path clear taken seriously, lot of good work. rev, and discussion, and ML review. q: how approach get user-level kind of review. allson AVT and SIP wg. jon: ask wg chairs directly to look. allison: doc that proscribed advancded... talking about RFC advancement. ============================================================== attention drawing cross-area discussion multiple addresses in Transport, for discussion: allison prelim discussion. group get attn drawn, and go off to deeper thoughts. - -- hosts have multiple addrs sometimes can find out (e.g. STUN) [private + global] IPv4 - private realm or global IPv6 - link-local (not site-local) and global multiple global addrs because of multihoming addr of add'l interfaces (e.g. SIGTRAN usages) SIGTRAN - fault tolerance. else mobile. - -- ways transport handles tcp not really sctp has lots of stuff. dccp explored mobility... probably experimental extension. spec has many negotiable features. niether one really looks at NAT traversal (or other ways that addresses may happen) - -- note: we have transport that has transport as well. SIP has multiple addre handling now ANAT in mmusic... primary addresses, but tell me which one will connect on ICE (internet connectivity establishment): mmusic. j rosenberg is principle designer primarily deal with presence of NATs how get "real" address. UDP focus diags based on STUN NSIS working on NAT/firewall traversal. if multiple addrsses... find oen that has least NATs (:)) and some preference decision. all doing things in different way. - -- crux of discussion same problem varied services w/differing breadth of soln. (ops and internet too) can we make it consistent - -- ops and int multi6 and HIP originally 10's of proposals. still 10's of goals, but getting coherent proposals. my (allison) view: strongest goal, make sure routing system scales when multi homing pushes it. not surviving long-lived transport. as transport folks, gotta look at multi6 proposals. transport-related. biggest ones NOID, HIP, WIMP est identifier, locator split take bundle of addr, and mask from session layer. (so things we've done... inadvertently, incoherently(?) done by yet another module somewhere else). generalize transport stuff? say, ICE. are ops/int identifiers compatable with transport goals? look at quality of connection? are there multiple layers that must consider questions? how coord? touch: some of this came up in tcpm. repeat here people ar econfusing what transport layer proto do once connected, vs. est conn in internet like conn a telephone. if opt how connect other end, do in app layer. changing transport to do it all for us, bad idea. nice to have mechanism we can hsare, but why put cruft in transport layers. like idea of something that decouples transport and endpoint addrs, a-la HIP. but don't confuse that with security. j rosenberg: confusing from fuzziness of differences between layers once over layer 4 session/transport confusing. this stuff falls at boundary. think agree w/joe. negotiation happens bot app, mid session, top transport...have app level guidelies about which better other. clear difference between that prob, choosing addrs...and don't have any session where don't have addrs. NOID/HIP - useful to initiate a session. once get there... then have session mgmt, then don't see multi6 as helpful which locators want to use for RTP. ICE/SIP can do a much better job. have criteria that aren't limited to IP info qos, ... stuff above what IP might use. when you said session...differentiation between ICE, SCTP and multi6 live. melinda shore: agree with jonathan. just because is a problem for transport layer, doesn't mean it's a transport problem xport problem. NAT traversal... multiple addrs, doesn't belong to endpoint. NSIS thing sounds weird. operates indpeendet of routing? dangerous. bc: I could talk for 1/2 hr. speaking as multi6 co-chair. we're not interested in nat traversal, no nat in ipv6. also specific q's to ask about stuff above l3. may not be same to apps people as trsnport people. must deal with legacy TCP, one address. two AAAA records are confused. other extreme, deal with apps doing path optimization. think point that multi6 proposal simple interface, like ipv6 socket with ipv6 address. running code will use, magic happns at layer 3.5. another class that doesn't want us to do that. Give feedback, what are the requirements? kfall: seed people's minds. having transport layer that use and have something other than IP underneath. if transport could use opaque strings, could replace underneath (not iP) as needed. could use other stuff. bag of transport identifiers. qiaobing xie motorola quinming: add to what's been said... having multiple addrs, happen for different t reasons. so that's a challenge. SIGTRAN for redundancy. no concept of ... flowing even with failure. challenge to unify scheme that handles multi. ruediger: generalizing good idea coordination a good thing too, but not too many. qos signalling would be simplified if session id instead of IP addr. afalk: clarification. way split up HIP. locator selection piece moved into RG ?: right now in wg, co-chair hip: for easy stuff. [gonzalo] session descripotion, dns. multiple servers, randomness... doing in research group. afalk: agreeing with me. passing some hints on which addr synergistic w/RG. happen there. allison: the final word on this is to coordinate. need more people to just look. Make sure not to do miscoordinating work, look at the work in other areas. Reach end of time. need to close. Nobody is rushing to lunch, so this must be an interesting way to end. |