trigtran@conference.ietf.jabber.com - 2002/11/20
[10:58] %% randy has arrived.
[11:13] %% mallman has arrived.
[11:15] %% Joseph has arrived.
[11:15] <Joseph> Scribing
[11:16] * Joseph has changed the subject to: agenda bashing
[11:18] %% SandyT has arrived.
[11:18] %% mlshore has arrived.
[11:19] <Joseph> shout: future direction before open mic
[11:20] * Joseph has changed the subject to: problem statement draft
[11:21] %% Aaron has arrived.
[11:21] <Joseph> Topics: What's the problem, strawman, partial deployment and security issues
[11:22] %% rafdalb has arrived.
[11:22] <Joseph> Not trying to change e2e; dealing with paths with long RTTs, transm errors
[11:23] <Joseph> Sample Strawman Architecture::
[11:23] <Joseph> Trigtran (TT) Routers send messages to host transport layer
[11:24] <Joseph> across an arbitrary path
[11:25] %% jhutz has arrived.
[11:25] %% starsu has arrived.
[11:25] <Joseph> hopefully be able to do so without updating all routers
[11:25] <Joseph> (to handle TT)
[11:27] <Joseph> Possible notifications
[11:27] <Joseph> - link up/down; discards (not congestion); path changes; bw change; others??
[11:28] <Joseph> Things that TCP "can't" know [or figure out?]
[11:28] <Joseph> Possible Receivers:
[11:29] <Joseph> Interested hosts notify TT routers
[11:29] <Joseph> How to do it?
[11:30] <Joseph> ICMP messages; unicast to transport; mulitcast
[11:30] <Joseph> What sending rate and archtect issues (firewalls, etc)
[11:31] <Joseph> What to do with messages, how to respond? Launch a probe, defer pkts, notify apps, adjust cwind
[11:32] <Joseph> Security considerations: triggers to adversly affect hosts/routers
[11:34] <Joseph> mic: S.Tavari (SUN): hard to detect what messages are real/waranted
[11:35] <Joseph> Karen (MIT): Pricing question: Triggers on how pricing may have changed
[11:36] <Joseph> Is pricing changes worth considering?
[11:37] <Joseph> Mic: Possibly split problem into 2 parts, one hop vs multi hop
[11:38] <Joseph> Spenser: continue that discussion later
[11:38] <Aaron> mic: was John Wroclawski, MIT
[11:39] <Joseph> Suggestion that pricing model may be out of scope as it is likely to be applicable past the Transport layer
[11:41] <SandyT> You're doing a great job with notes :)
[11:43] <Aaron> looks like Joe fell offline, I'll try to fill in scribing
[11:43] <Joseph> i'm still here
[11:43] <Aaron> sorry
[11:43] <Joseph> people can pitch in though ;)
[11:44] <Joseph> general discusion of how you could use the information
[11:44] <Joseph> at the end hosts
[11:45] <Aaron> John W. suggested that an alternative architecture would be having the access router notify the associated host and the host could notify the other end
[11:45] <Aaron> This represents a different solution to the simplified case.
[11:47] %% starsu has left.
[11:47] <Aaron> Spencer: but the associated host may have connectivty problems whch prevent it from sending anything
[11:47] %% Joseph has left.
[11:47] %% Joseph has arrived.
[11:47] <Aaron> sally floyd giving a presentation
[11:47] %% starsu has arrived.
[11:48] <Joseph> Floyd on generic problems with triggers
[11:48] <Joseph> Misleading reports; extra traffic; DoS; floods
[11:49] <Joseph> So why consider? Learn from past triggers (source quench, MTU Disc)
[11:50] <starsu> No routing
[11:51] <Joseph> (note no mechanisms or routing in this discussion)
[11:51] <starsu> Link back up?
[11:52] <Joseph> Could avoid a backed-off retmt timer
[11:52] %% alcor has arrived.
[11:53] <Joseph> How to detect? Likely link-level, other solution is probing
[11:53] %% alcor has left.
[11:54] <Joseph> Non-congestion loss
[11:54] %% starsu has left.
[11:54] %% starsu has arrived.
[11:54] %% SandyT has left.
[11:55] <Joseph> Well TCP assumes loss = congestion (without specic info) reduce cwind
[11:55] %% _ruffi_ has arrived.
[11:55] %% SandyT has arrived.
[11:56] <Joseph> triggers could: undo cwind changes, drop only slightly?
[11:56] <Joseph> Notify the app, other reactions
[11:57] <Joseph> Link level only solutions exist, FEC, etc
[11:58] %% Joseph has left.
[11:58] %% Aaron has left.
[11:58] %% Joseph has arrived.
[11:58] * Joseph thinks we're killing the jabber server
[11:59] <Joseph> Other transport level solutions are being proposed
[12:00] <Joseph> Sorry missed mic discussion
[12:01] %% Aaron has arrived.
[12:01] %% rafdalb has left.
[12:01] %% rafdalb has arrived.
[12:02] <_ruffi_> teste
[12:02] %% randy has left.
[12:02] <Joseph> General non-congestive loss trigger
[12:02] <Joseph> Losses affect [most] applications
[12:03] <Joseph> again losses = congestion for TCP
[12:03] <Joseph> what to do with info
[12:03] <Joseph> notify app, decrease packet size
[12:04] <Joseph> Not discussed: Link down, bw increase/decrease
[12:04] %% starsu has left.
[12:06] <Joseph> next up wireless transport issues
[12:06] <Joseph> on noncongestion triggers, why decrease cwind at all?
[12:07] <Joseph> or packetsize
[12:08] <Joseph> Question: can apps use this information
[12:08] <Joseph> (that was jeff)
[12:08] %% mallman has left.
[12:09] %% starsu has arrived.
[12:10] %% tbamonti has arrived.
[12:10] <Joseph> Gorry: Need to react correctly when you get complementing messages, link up/down... could possible be from different paths
[12:11] %% tbamonti has left.
[12:11] <Joseph> be conservative by using the 'good' information
[12:12] <Joseph> Alison/Sally: Need to consider tradeoffs (small probes etc)
[12:12] %% SandyT has left.
[12:13] * Joseph has changed the subject to: protocol considerations (alper Y.)
[12:13] <Joseph> identify link-layer events
[12:14] <_ruffi_>
[12:14] <Joseph> define protocol for event notifications
[12:16] %% mallman has arrived.
[12:16] <Joseph> Picture of server client it shown, demonstrating 3 layers of indirection... trigger straight to host (mobile laptop), trigger to cellphone connected laptop
[12:16] <Joseph> (2hop), and trigger to wireless bridge (mulit hop)
[12:17] <Joseph> Aaron: are you excluding the case that the access router has changed
[12:17] %% john loughney has arrived.
[12:18] <Joseph> Alper: not necessarily
[12:19] <Joseph> Who should receive notification? all hosts, registered hosts, server?
[12:19] <Joseph> Tricker as the trigger needs to traverse multiple hops
[12:20] %% SandyT has arrived.
[12:20] <Joseph> nonregistered hosts are likely not interested
[12:21] <Joseph> possible for TT routers to have multiple interfaces, and possible to have multiple TT routers... selectors needed
[12:22] <Joseph> Alison: This may be getting to specific for the BOF,
[12:23] <Joseph> Alison: This sounds like solutions, and more explicit than expected
[12:23] <Joseph> Shout: Use your slides to just highlight the issues and implications
[12:24] %% Joseph has left.
[12:24] %% john loughney has left.
[12:25] %% Joseph has arrived.
[12:25] <Joseph> Security issues: Spoofing/Authentication
[12:25] <Joseph> Discovery as you increase hop distance
[12:26] * Joseph has changed the subject to: Caveats
[12:27] <Joseph> Started with L2 triggers and handovers on wireless links
[12:28] <Joseph> allowing for fast handovers coupling L2/L3, and fast IP handover at L2 speed
[12:28] <Joseph> Opinion: IETF should not pursue this work further
[12:28] %% jis has arrived.
[12:28] <Joseph> as implications are questionable
[12:29] <Joseph> s/implications/protocol implications/
[12:30] <Joseph> revisit if IETF decides to consider AP as IP devices
[12:31] <Joseph> How does TT routers know where to send the information
[12:31] %% mrose has arrived.
[12:32] <Joseph> Larger issue: what if most of the losses on the network are not due to congestion
[12:33] %% john loughney has arrived.
[12:34] <Joseph> Future Wireless networks at higher frequency bands may produce a larger number of non-cong. errors
[12:34] <Joseph> Some one catch the mic question?
[12:35] %% jm has arrived.
[12:36] <Joseph> Mic: home Sat network experience: seen good % of loss (10%) and TCP does behave incorectly
[12:37] <Joseph> MIc (Andrew): That's how it is when you loose that many packets due to non-congestion
[12:38] <Joseph> Mic: How do you tell the difference between fale possitives and real possitives?
[12:39] <Joseph> Charis: Good point, but were not here to solve the problem today
[12:40] %% john loughney has left.
[12:43] %% Joseph has left.
[12:43] %% Joseph has arrived.
[12:43] <Joseph> Mic: We're changing the way the network is worked/looked at... middle of the net is no longer just wires. Needs more than the IETF.
[12:43] <Joseph> (cont): Failed at this in the past (MTU disc)
[12:45] <Joseph> Sally: Link-up notifications would only need to go to one end, discresion on how it would work is that a single probe for conectivity and a slow-start to old value... nothing to cause congestion collapse
[12:47] <Joseph> Sally; Bandwidth increases not too useful to transport b/c it limits itself
[12:47] <Joseph> Pat: Do routers have the information to do this?
[12:48] <Joseph> (cont): CRC errors, can't tell who's packet it is b/c you can't trust the packet
[12:49] <Joseph> Chairs: There are situations where this is not the right solution... cellular may have more knowledge, and certian other systems, good point
[12:50] <Joseph> Randal Stewart: Mulit-homed... may make usefull info of link-down... use info to quickly disable a link and move traffic over
[12:51] <Joseph> (cont): Switching hats - employer - too much overhead for the forwarding path.. and more state for the router (registrations)... seems poor for the middle, much more practical at the edge
[12:52] <Joseph> Andrew: Multi-hop case: want to avoid state (registration info). You want L2 triggers also.
[12:54] <Joseph> Reinar: If the link is down, TT router holds on to the packets and forwards them on (maybe some and not all) requires no explicit information
[12:54] <jhutz> that sounds really useful, especially if the link is one that bounces up and down a lot -- you can do a lot better if you know _when_ to retransmit
[12:56] <Joseph> John: Source quench didn't work b/c routers didn't know where to send it, and
[12:57] <Joseph> (cont): this whole information model has been looked at before
[12:58] %% jm has left.
[12:58] %% _ruffi_ has left.
[12:59] %% mlshore has left.
[12:59] %% _ruffi_ has arrived.
[12:59] %% mrose has left.
[13:00] <Joseph> Richard Nelson: (highly paraphrased, sorry) With registration and link up... when you register with a router, if you go down, when you come up, the registration may be stale as your with a different access net
[13:01] * Joseph : mic question was too deep for Joseph to grasp (ie he lost me) :)
[13:02] <Joseph> Chair summary: If links aren't wires, they should be... what the best we can do currently
[13:04] <Joseph> John: Would you consider framing it as solving a problem/issue of [last hop link]
[13:06] %% hta has arrived.
[13:07] * Joseph has changed the subject to: thoughts on link up/down
[13:07] %% _ruffi_ has left.
[13:07] %% Aaron has left.
[13:08] %% _ruffi_ has arrived.
[13:08] <_ruffi_>
[13:09] <Joseph> Chairs: Mailing list will have discussion and meeting notes
[13:09] <jhutz> Please try to get those URL's into this log, if you can see them...
[13:09] <Joseph> Subscribe: trigtran-request@ietf.org
[13:09] * Joseph works on digging up URL standby
[13:09] <jhutz> thank you...
[13:10] %% jhutz has left.
[13:10] %% starsu has left.
[13:10] <Joseph> btw body " subscribe" for mailing list
[13:10] %% rafdalb has left.
[13:10] <Joseph> http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/trigtran/2002-11-20.html
[13:11] * Joseph has changed the subject to: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/trigtran/2002-11-20.html
[13:11] <Joseph> That is the archive of this meeting
[13:11] <Joseph> Charis: Thank you, meeting over
[13:12] %% Joseph has left.
[13:13] %% SandyT has left.
[13:13] %% _ruffi_ has left.
[13:14] %% mallman has left.
[13:21] %% hta has left.
[13:26] %% jis has left.
[13:26] %% jis has arrived.
[13:26] %% jis has left.
[13:35] %% randy has arrived.
[13:35] %% randy has left.
[13:36] %% randy has arrived.
[13:36] %% randy has left.