Re: [TERNLI] Notes from tonight's ad hoc

["Spencer Dawkins" <[e-mail]>]

Did we end up with a list of lists? This one seemed helpful. Others I think 
we talked about were

- list of WGs, BoFs, and BoF requests, with history,

- list of things that transports might care about,

- list of things they might do "if they knew",

- list of canonical land mines (security, host security considerations, 
state in the network, complexity of mandatory mechanisms plus "hints" and 
the interaction between mandatory mechanisms and hints, and transport 
considerations for notifications, which I forgot to mention but was a big 
deal in TRIGTRAN - not OK to send a million "link down"s in the reverse 
direction with no congestion avoidance, etc.)

Were there others?

Who is holding the bag on action items?

(signed) Curious


> On Tue, Jul 11, 2006 at 07:52:02PM -0400, Spencer Dawkins wrote:
>> Were stuck into jabber log, at
>> http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html, at Lar's
>> suggestion.
>>
>
> One thing that I took away from yesterday was that it may be productive
> to build a pair of tables to describe the problem space; one table
> for "significant path changes" that might be passed up to the transport,
> and one table for "significant path desires" that the transport can
> pass down.  In each table, we could have a row for each piece of data
> and columns that describe the time-frame of relevence (per packet,
> within an RTT, per-connection, etc), any existing "point" solutions, and
> whether or not the solutions are deployed now, or still research.
>
> There are a lot of starting points to feed this, including the IAB
> link indications document and some of the mobopts work.
>
> My thought is that once we have all the diverse things we're talking
> about clearly listed, it might be easier to pick out commonalities or
> visualize what an architected solution could look like, and also what
> the current accidental architecture looks like.
>
> Does this sound like a reasonable next step to take?
>
> -- 
> Wesley M. Eddy
> Verizon Federal Network Systems
>