[Trigtran] TRIGTRAN IETF 56 BoF Notes - please check for misquotes and confusion

[Spencer Dawkins <[e-mail]>]

Thanks to Kevin and Tom for taking really good minutes!

This is what Carl and I know, so far - please let us know if we
got it wrong (in spite of our good note-takers)

Spencer, for Spencer and Carl

------------------------------------

Triggers for Transport BOF (trigtran)

Thursday, March 20 at 0900-1130
===============================

CHAIRS:	Carl Williams <[e-mail]>
		Spencer Dawkins <[e-mail]>

Thanks to our minutes-takers:		
Kevin Fall <[e-mail]>	
		Tom Hiller <[e-mail]>

Revisionism - Carl and Spencer were experimenting with the 
terms "connectivity interrupted" and "connectivity restored" in 
the framework draft and in the BoF, because "link down" 
and "link up" didn't map cleanly onto multi-hop subnetwork 
technologies, but we're going back to "link down" and "link up" 
as "clear enough" - and these terms will be used in the BoF 
minutes.

BoF Coordinates:

General Discussion: [e-mail]
To Subscribe: [e-mail]
In Body: subscribe
Archives:
www.ietf.org/mail-archive/working-groups/trigtran/current/maillist.html

BOF agenda and description:
http://www.ietf.org/ietf/03mar/trigtran.txt

Final Agenda:

- Introductions, Scribes, Jabber Scribes, Agenda-Bashing

- Status Update and Strawperson Statement of Work

- Issues identified in Framework draft

- Questions leading to a WG charter

- Next Steps to a TRIGTRAN working group?

Status Update and Strawperson Statement of Work
-----------------------------------------------

There are two current Internet-Drafts produced by Carl and 
Spencer as straw-person proposals on a problem statement and a 
framework. These drafts are

	draft-dawkins-trigtran-framework-00.txt
	draft-dawkins-trigtran-probstmt-01.txt

This BoF is a "second BoF". The first TRIGTRAN BoF was held at 
IETF 55, and focused on the problem statement; this BoF focused 
on what we learned from doing a framework proposal and on next 
steps to chartering TRIGTRAN as a working group.

Spencer made the canonical TRIGTRAN disclaimers:

- TRIGTRAN isn’t L2 triggers

- TRIGTRAN trigger delivery not guaranteed

- No notification ACKs; partial deployment scenarios

The framework draft considers 3 canonical triggers:

-	Link up
-	Link down 
-	Packet Discarded by subnetwork, not due to connection

"Link Up" seems easier in the short term.  There is some 
previous thinking on it: see Phil Karn’s posting on "Kicking 
TCP" on PILC list 3/2000m available at  
URL: http://pilc.lerc.nasa.gov/pilc/list/archive/0691.html

As for "Link Down", this notification "should" make sense. It 
does make sense intuitively. The problem is that the response 
might be application-specific - some TCP senders might wait 
longer to close a TCP connection, while others might give up 
sooner. Is there a canonical response? We need to understand 
the applications better before we can posit how to respond to 
this notification.

As for "Packet Discarded", we've realized that in a cellular 
environment this notification may result from a handoff - if 
so, the TCP sender would already have received a Link Up 
indication from the TCP receiver over its new connection path. 
Conceptually, a TCP sender should slow-start when path 
bandwidth changes, but if the mobile has merely moved from a 
lightly loaded cell to another lightly loaded cell, TCP could 
just continue in its current state without going to slow start. 
The new cell is as likely to be less congested as it is likely 
to be more congested, so ignoring the handoff, as TCPs do 
today, is still a reasonable strategy. Would telling the 
transport really help?

Spencer summarized a private conversation with Mark Allman 
as, "Gee, maybe TCP does pretty well often times on its own. 
You may be able to find cases where you could do better with 
notifications, but by the time you make sure the response to a 
notification doesn't have undesirable side effects in other 
cases, TCP doesn't look so bad"

Co-chair summary Link Up seems ready for prime-time, Link Down 
may be in the near future; Packet Discarded seems less ready.

Spencer (and Carl) proposed a strawperson Statement of Work:

- spin up working group and do ‘link up’
	Specify response for dup pkts during RTO
	Safe, good consensus

- investigate ‘link down’ semantics
	What should transport do here?  

- investigate explicit mechanisms
	Can we send OOB signals in the Internet in 2005?

- build consensus on wish list for IAB/IRTF investigation?
	Horizontal handoff, non-congestion loss, corruption
	Send wish list to Leslie and Vern and ask for help
        (this is something mobileIP and others are doing)

-- Q and A --

Sally Floyd: terminology: why “connectivity restored” vs "link 
up"? One link up might not have anything to do w/e2e 
connectivity

Spencer: You’re right — the previous ‘link up’ term is more 
appropriate

Bernard Aboba: need to be clear about the meaning of 
notifications. There's a distinction between link ‘up’ 
vs ‘fully functional’ - a link can be “up” but may not provide 
very useful connectivity. It can be quite tricky as to  just 
when you send the trigger.

Spencer: Would notifications about nominal BW changes be useful?

Bernard: I was just thinking re link up; but if I was told of a 
rate change that doesn’t seem so obviously relevant

Kevin Fall: you may have cases in which the link is ‘up’ but 
error rate is rather too bad to be very useful.  This has been 
explored some time ago in SCPS.

Phillipe Gentric: knowing a rate change could be quite helpful 
for streaming media

Spencer: Maybe a bandwidth change would be some form of maximum 
[a speed limit through a link], so the indicator is essentially 
saying you might as well not go faster than that to the 
transport.

Allison Mankin: maybe we are out of scope here; we don’t really 
have links that tell us their max bandwidth at the moment

Sally: It's not obvious what scope should be; some things have 
been investigated but others haven’t been.  At a minimum, maybe 
TRIGTRAN could write a problem statement. This group could 
define the trigger; sending the entire problem to a research 
group may not be enough, but a problem statement might well be 
appropriate.  

Eg. DCCP partial checksum issue came up.  Should you allow 
corrupted data to be delivered to apps [or to lower layers].  
Or should it be marked somehow as corrupted.  Where would this 
sort of issue be addressed? perhaps here, or perhaps somewhere 
in IRTF.  

Another: as we build transport protocols robust to re-ordering, 
[and there is no reason they couldn’t be]--- would you want a 
way for the transport to tell some lower layer that it robust 
to re-ordering so feel free to re-order.  So, I don’t know.  
Not clear where speculative, fleshing-out activities should 
take place.

Spencer: We have been trying to maximize the amount of sanity 
we appear to have.  We were trying to stay grounded in minimal 
notifications, not to spend time thinking about what to 
usefully speculate about. Now that we've been through a 
strawperson framework, maybe it would make sense now to add 
some of these speculative things to the discussion topics.

Mark Handley: Various forms of these issues have arisen over 
the years.  We don’t have good institutional memory.  If we 
investigate why *not* to do something, we should write this 
down somewhere, so we can remember why we *don't* do things.

Spencer: Yes, I found some things like this looking over older 
discussions.

Allison Mankin: We have a group of community members in the 
IETF who are largely not researchers; there are some 
interesting questions (e.g. how long to wait, what to do, is it 
really up or down, etc).  Just getting this right is useful – 
there is engineering to do with issues like "link flapping".  
We aren’t inventing a research group here.  I’m trying to not 
sound too ‘top down’ here.  We would not want to include the 
researchy stuff in the charter.  Probably having a wish list 
possibly for another group might be good, but we should not be 
doing work such as congestion handling here.

Bernard: The more I learn, the more I would like to have a 
document that describes the general characteristics of various 
links.  A link tutorial for the group would be useful.  Of the 
existing literature, what are the results and conclusions?  
These are not static characteristics but dynamic ones.  I take 
this to mean a survey document.  This would be the first item 
of order to complete. It's not exactly the same stuff that PILC 
did.  Maybe different than PILC because here we are concerned 
with signaling, which is more dynamic.

Allison: You are suggesting a sort of survey doc?  That would 
be part of the charter[?] hmmm.

Spencer: TCP-SAT WG produced a doc that summarized the research 
topics.

Allison: yeah, maybe ok.  We would like to have a well and 
narrowly focused group.  This is my answer to Sally.  Now we 
have Bernard's suggestion.

Spencer: Maybe we could do this in parallel [both the research 
and engineering-ish documents]

Aaron Falk: [former chair of TCP-SAT] I’m not sure that the 
research doc was so useful.  I wouldn’t be opposed to seeing it 
again, but wouldn’t want to take WG resources away from other 
tasks.  There are all sorts of subtleties.  The charter must be 
narrow and well focused. I would rather go deep than broad.  I 
don’t see that a TRIGTRAN research mechanisms document is a 
great investment of resources.

Gorry Fairhurst: there are many things we could signal, but we 
don’t know what we would do.  I think doing a big survey would 
unearth lots of stuff we probably don’t want to deal with.

Spencer: Doing the framework revealed a fairly rich set of 
things that come up.

Bernard: Given a media, how reliable is an indication?  This 
sort of documentation could be quite useful.  So, a [control] 
system observing an indication has to have some understanding 
of what to believe.  This applies to rates also.  The question 
is how reliable is it, how much skepticism should be applied 
when receiving a trigger.

Spencer: Carl and I were assuming it would be helpful to know 
what different subnet technologies had the capability to send.  
Bernard is perhaps stating that the mapping of link condition 
to trigger could be more formal than we had been thinking.  
Hmmm.

Allison: Maybe an appendix could include examples that could be 
cautionary or provide examples.  Gathering those would be good. 
The working group could contribute these.

Vince Park: I agree w/Bernard.  It is difficult to decide what 
to take as an indication and how to interpret it.  Probably a 
good idea.  Has come up in mobileIP, MANET, and others.  
Ultimately you have to decide how to map L2 type information 
into a higher-layer indicator. May be bigger scope than TSV-
only.

Ethan Blanton: for some triggers we aren’t sure we need a 
*protocol*.  Not sure it is worth putting that much energy into 
a protocol until we are sure we need one.

Aaron Falk: We're not just talking about the format of "bits on 
the wire". We need to define the semantics of what 
notifications you get and how you respond.  None of that stuff 
has been hashed out.  I believe some of these things may be 
valuable, but maybe there are cases where there are problems.  
There is work to do there.

Ethan: I didn’t mean to indicate that we shouldn’t do this 
work.  Just maybe a first-order item may be not to define the 
protocol, but whether or not a small subset of triggers are 
needed given certain links.

Spencer: I would like to agree.  The mechanism appropriate for 
link up is different from every other notification we’ve talked 
about.  If all we have to do is link up, we don’t need the 
whole framework.  Is this responsive to your question?

Ethan: yeah, I think so.  If you carve out a space that doesn’t 
need a protocol, you could still be concerned with what to do.

Rick: from Mobile IP, we have been playing w/L2 triggers.  
Getting their semantics sorted out is important.  We may need 
them for all sorts of things.

Mark Allman: I’m not so concerned about ‘link up’ per-se, but 
exactly what you should do with it should be taken with some 
caution.   (e.g. DCCP with this indication would do what 
exactly?)

Spencer: We’ve been encouraged to look at other transports 
(e.g. SCTP).  Now that DCCP seems to exist, we should be 
looking there too.

Sally: I agree the question is open as to implicit vs explicit 
signals and that we need definitions for explicit ones and 
descriptions for implicit ones.  Explicit signals might not be 
the right answer.

Mark Handley: Does the sender of the signal need to know about 
all future transports?  This is a complex space—interactions 
with lots of things [tunnels, security whatever].  Need to be 
careful.

Spencer: My experience is that transport area is cautious.

Randall Stewart: I also don’t know what I would do on link-up 
in SCTP stack.  Other than (some) relationship to heartbeats, 
I’m not sure how useful this is.

Spencer: I had thought TCP people want link up and SCTP people 
want link down, based on conversations at IETF 55.

Randall: I feel somewhat uncomfortable with link down given the 
possible DoS issues.

--- Issues in the framework draft—

Aaron Falk suggested that we focus this discussion on Link Up, 
because we haven't gotten consensus on another notification 
that's compelling

Spencer: link-up needs very little framework, and other stuff 
isn’t baked yet. The framework document is not really a 
completed framework.  We are exploring an approach.

Aaron: Spencer, I’d like to suggest that we might have a 
consensus in the room that there is strong support for link-up 
and maybe some opposition to others.  If you accept that, the 
framework is somewhat superfluous in the context of just doing 
link-up.  Take a poll of the room to see.

--- Agenda and WG charter and scope issue ---

Spencer: I appreciate your suggestion re going forward on link-
up.

Aaron: What might be an acceptable scope of work for this WG is 
the question.

Spencer: How about link-up?  Is there is consensus that working 
on link-up would be just fine?

*** Room Consensus was that Link Up is just fine ***

Aaron: Does anyone this think would be a *bad* idea?

Spencer: Yes, and please tell us why?

Spencer: If we charter as a WG, I'm looking at whether this 
would be in scope.

Joe Zebarth: It appears to be premature if this will move 
beyond a BOF.

Spencer: What questions remain to be answered?

Joe: Are you proposing a new protocol or mod to existing one?  
If I’m sending UDP say do I get one of these triggers?  Are we 
modifying TCP or doing a new protocol or what?  We need more 
info to agree or disagree for a WG formation.

William Ivancic: There are unanswered questions regarding the 
usefulness of link-up. This isn't IETF-ready yet.

Spencer: The criteria for having an item in the WG charter is 
not that we already know the answer, but that we are pretty 
sure we could come up with one.

Dick Knight: I’m still confused.  What is the clear problem 
statement?  Most of this link layer stuff will sort itself 
out.  I’m not sure why you are working this problem.  Is this 
going to work in an MPLS network?

Reiner Ludwig: To those people who said ‘no’, people aren’t 
convinced we have a problem.  Various people don’t know what to 
do with it.  I don’t think people in this room are convinced 
there is a problem.

Aaron: I think part of the problem is that not all these people 
have been at the places where this has come up before and that 
the drafts don’t fully capture these experiences.  E.g. the 
reference to Phil Karn’s stuff in PILC.  The people here that 
are familiar with the PILC document are not the ones that have 
objected [except Reiner]. Responding to Reiner in particular, 
there are some questions regarding SCTP, DCCP, and TFRC.  One 
way to go is to take the suggestion from the PILC doc that you 
re-transmit packets at the routers [which doesn’t require 
changes in end stations].  Part of the problem here is not 
everybody understands all the issues.  We may need to talk 
about this—there isn’t a consistent sense as to what is on the 
table.  2 pieces of the problem:  should IETF be trying to 
solve this, should the IETF try to solve this and what is the 
form of the solution so people can see it is not dangerous.

Spencer: I do have a couple of slides here to present that 
might help.  Phil Karn’s proposal is best described in a 
posting on the PILC list from 3/2000.

Mark Handley: Trying to summarize.  A general strategy used in 
many of our transport protocols is exponential backoff.  You 
would like to not have to wait for exponential backoff if you 
know the link has actually failed.

Spencer: So, like in TCP, this could be quite some time [to 
wait].

Bernard: I think there is some problem getting the timer to the 
right point.  Eg. There can be rate changes between media [e.g. 
between 802.11 and GPRS].  Question is how long it takes to 
adjust.  Also, sometimes the adjustment can be 2-3 orders of 
magnitude.  The first thing you need is a well-defined problem; 
next is what does the literature say?  Does this literature 
solve the problem, or is something else needed?  If you go 
through this logically, then get to the end and figure out 
whether you have solved it [or not].  Then you have a logical 
problem statement and you figure out what is left.  (e.g. if 
the receiver changes rate dramatically, does or how does the 
sender know)?

Spencer: First thing I’m going to show you now is generally 
about the framework; next is more specific to TCP {“kicking” 
TCP}.  Kicking TCP doesn’t appear to be so difficult, but I’m 
afraid if we go beyond this we need much more organizational 
machinery.

Mark Handley: please don’t talk only about TCP; the exponential 
backoff is ubiquitous for other transports too.

{Explanation of slides – lots of details here, see the slides, 
in particular the one titled "If we really ‘kick TCP". Phil 
Karn, “Kicking TCP” March 2000 PILC list posting reference 
appears at the top of these minutes}

Sally Floyd: I would feel more comfortable with a problem 
statement before the framework.  Basically what Bernard has 
suggested.  I would feel much more grounded to start there.

Spencer: I agree completely.  We did some problem stmt work up 
front; it would be appropriate to continue from there.

Bernard: these indications have effects on things other than 
TCP.  For example, maybe I need to update my address lease.  
So, that would certainly change things if I lost my address!

Allison: This is the third in a series of BOFs that seems to be 
trying to not generalize the overall triggers problem.  Is this 
part of the Internet area; seems that it isn’t happening there 
either.  Nobody seems to want to own it.  I have a general 
question — I should ask “how pressing is this problem”?  How 
often do we get caught in this state?  Maybe this inconvenience 
isn’t worth the effort [like building the WG].  Maybe we should 
take a poll as to whether you have this problem?

Spencer and Carl: Hand poll was maybe 30 people or so that felt 
they had this problem.

Reiner: In TCP over Sat, Wideband CDMA, etc.  this just happens 
all the time, its not a big deal.  Maybe it is for something 
else.  For wireless wide-area networks, this just happens.  Can 
we get comments from the other people that said yes?

Bernard: it isn’t a big problem on 802.11, and again you have 
to be really careful about how you treat the indications [what 
sort of filter you use]

Allison: so we might say don’t do this for 802.11.  Now I think 
we take a charter proposal, unless there is some objections?

Alex Adieu: is there an option to do both link up and down? 

Spencer: Well, no, not yet

Alex: Are we going to ask this question?

Carl: Does anything other than link-up make sense for a charter?

Kevin: there is an observation that these indications can 
affect other layers of the stack.  If we charter narrowly, 
where will this be addressed?

Tom Hiller:  there is some advantage to link down in 3GPP

Spencer: We have been assuming these indications are pretty 
much un-authenticated.  So therefore what they can indicate is 
limited.  So we have been living under this constraint.

William: but can’t I have similar issues with link up?

Spencer: I wasn’t so concerned with getting a link up than a 
link down.  It doesn’t seem as risky as link-up - the network 
effect of link up is the same as an RTO timer popping.

Mark Allman: it's all in how you scope the response to an 
indication.  Link-up could be dangerous if you blast.  Not if 
you are conservative, I would think.

Spencer: Comments on sending some of this to the IRTF?

Kevin: Who covers things covering various layers?  Is it 
possibly IRTF?

Aaron: Kevin, maybe this could be a result of just doing it.  
The process can be adapted.  I’m an advocate of being closed 
and well defined.  I’m increasingly unhappy with how long the 
turn around time is on documents.

Spencer: Is it worth talking about “non-engineering” things 
here?

Sally: It seems like there are architectural issues here.  
Having an IRTF home for this seems perfectly plausible to me.  
Whether it is an IRTF group or just a bunch of people doesn’t 
seem so important.

Spencer: What we are talking about is can we discuss things 
that might be outside the WG?

?? – I know we’ve talked about link up and link down.  What, in 
total, are we talking about?

Spencer: In my complete list, including researchy topics, I had 
described link up, link down, packet discard, possibly 
horizontal or vertical handoff, and maybe indication of 
corruption losses

Sally: I think a group of people writing about particulars 
could also write about more arch/speculative things too

Gorry: We touched on timescales; we’ve moved to link up/down, 
ok.  There is a semantic gap to what the link understands and 
what we are looking for.  But we need to understand the 
filtering better.  There is work to do that is technology 
dependent.

Allison: This WG is not going to spend lots of cycles trying to 
have architectural discussions.  It is going to spend its time 
working on the work.

Spencer: yes

Allison: It's going to do the work, right?  Don’t spend too 
much time carefully placing the work [that we don’t intend to 
do here] somewhere else. 

Spencer: Allison, can we go forward?

Allison: I’m going to wait for a charter proposal from you.  It 
should include milestones, etc.  I think we have gone as far as 
we can go so far.  No further progress can be made without the 
proposal.  My sense of the room is that the work is compelling. 
I don’t need any more info. That was the last question I needed 
to answer to proceed.

Spencer: Are we going the right direction toward a charter?

Allison: You need to say this is a real-world problem.  Scope 
the work carefully.  Charters are contracts.  Want to make sure 
the folks here are committed to doing engineering work on the 
problem.  Mark Handley reminded me that in the PILC Advice to 
Internet Subnetwork Designers (LINK) Internet-Draft there is 
(almost) a BCP how routers might use link indications to hold 
packets when links go down.  Be careful about security 
considerations and scope.  There has been a lot of chatter in 
small groups regarding lightweight semi-secure mechanisms for 
protection w/out full crypto.  Then we show a WG charter 
proposal to IAB/IESG, chairs participate in this discussion, 
then to the full IETF.  Then we have consensus of everybody, 
then we have a contract.  Then we hold to it very closely.  By 
then it has IAB review and IESG approval and is advertised to 
others.  This then might involve liaison with other standards 
bodies (IEEE in this case seems interested).

Spencer, after closing remarks:  Has anyone looked at the 
purpose built keys (PBK) draft?
_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran