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

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 11 Jul 2006 19:52:02 -0400

Were stuck into jabber log, at 
http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html, at Lar's 
suggestion.

Spencer

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 12 Jul 2006 09:35:56 -0400

> http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html, at Lar's 

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Jul 2006 10:44:06 -0400

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

---

From: Mark Allman <[email-masked]>
Date: Thu, 20 Jul 2006 14:12:55 -0400

> 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.  

This seems like a reasonable first step to me.  I would further winnow
the list of things to be passed up as "characteristics that impact
performance".  I.e., there is no use telling TCP that some random AP
switched from channel 6 to channel 11.  TCP does not care.  Now, if that
change results in more corruption or a lower bit rate then the TCP would
care about the latter.

From there then we can organize it and figure out where the lowest
hanging fruit really is.

My two cents.

allman

---

From: "Kevin Fall" <[email-masked]>
Date: Thu, 20 Jul 2006 19:09:14 -0700

Channel change might not be so exciting, but stuff like "I switched AP to a
different network" might be interesting.... and of course, data rate change
(e.g. 802.11b can support 4 rates).  802.16 has different convergence
sublayers it can use, which potentially affects mtu (gag).

Then there is the issue of L2 flow control, and the sort of curious stuff
linux does when it feels "locally" congested {where it basically acts as
though it recv'd a 'congestion experienced' indicator in an ack}.

- K

> -----Original Message-----
> From: Mark Allman [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 11:13 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [TERNLI] Notes from tonight's ad hoc
> 
>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 21 Jul 2006 09:06:19 -0400

> sublayers it can use, which potentially affects mtu (gag).

802.16 also has adaptive modulation and coding that alter the rate of
the channel and may vary as the distance between a base station and
subscriber station changes.  Adaptive coding is common for satellite
links as well.  It seems like this type of event could be useful to
signal if it resulted in more than a doubling or halving of capacity, as
a simple filter.

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Jul 2006 07:43:52 -0400

> signal if it resulted in more than a doubling or halving of capacity, as

One way to look at this is that the "type of event" is not at all
important to communicate.  The real thing to get across is the available
capacity has changed somewhat dramatically.  Does it really matter if
this is because 802.11 dropped us from 11mbps to 2mbps or some BoD
system just allocated us a ton of capacity or we moved much closer to
some access point / basestation and now have a much better signal?

Does this make sense?

allman

---

From: Michael Welzl <[email-masked]>
Date: Fri, 28 Jul 2006 14:06:04 +0200

> some access point / basestation and now have a much better signal?

A lot!

I was about to say something similar in case the discussion
would have moved further in this direction (signaling irrelevant
details about link layer occurrences to the transport layer).
I think that any comunication from lower layers up to the
transport layer should be converted to a transport-layer-related
format (where we're interested in things such as the RTT,
capacity (even though this is usually not available at the
transport layer - but it's an upper limit, so why not
communicate it?), all kinds of traffic related information
(e.g. imminent sudden growth), ...).

I don't want to turn this into an acedemic exercise - all
I'm suggesting is to think in such terms when looking at
link layer events that should somehow be communicated to
the endpoints.

Cheers,
Michael

---

From: "Kevin Fall" <[email-masked]>
Date: Fri, 28 Jul 2006 05:16:18 -0700

I'm not sure how clear-cut it is.  E.g..  a path change might imply a
likelihood of a significant capacity and latency change.  A capacity change
due only to modulation change would likely affect the latency less
drammatically, I would think.  On the "other other" hand, the system could
generate two indicators on a path change :P.

- K

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 28, 2006 4:44 AM
> To: [email-masked]
> Cc: Kevin Fall; [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Fri, 28 Jul 2006 14:19:43 +0200

> generate two indicators on a path change :P.

yep: two indicators.

cheers,
michael

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Jul 2006 08:56:08 -0400

> likelihood of a significant capacity and latency change.  A capacity
> change due only to modulation change would likely affect the latency
> less drammatically, I would think.  On the "other other" hand, the
> system could generate two indicators on a path change :P.

Right... but, the transport isn't going to be able to figure all this
out any more than the link-layer.

I guess I see the signals as either ...

  + Giving the transport something it can directly use.  E.g., the
    available bandwidth just increased from 2Mbps to 11Mbps.  E.g.,
    the flow experienced congestion.  E.g., some probability of the
    fraction of losses due to corruption.

    These are different from less-directly-useful information like
    "switched to a new AP" or "am now using a different coding /
    modulation scheme" which are much less directly applicable. 

  + Giving a generic signal that *something* has changed and it likely
    matters and so the transport should re-init itself (e.g., forget the
    SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.).

allman

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 28 Jul 2006 14:50:07 -0400

>     SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.).

Is it possible to generalize this to say that signals should either
carry specific actionable information or request specific types of
actions?

This means:
"Modulation changed" is a bad signal to implement.

"Available capacity changed from X to Y, please probe" is a good signal
to implement, and could be generated in response to a change in
modulation or any number of other things.

"Registering a new Mobile IP CoA" is a bad signal to implement.

"Please reprobe path state" is a good signal to implement, and could be
generated in response to a MIP CoA update or several other events from
mobility or multihoming mechanisms.

I guess this might simplify our task into categorizing the actions that
each layer might implement, and defining a signal for each class of
actions (with optional additional data to accompany the signal such as X
and Y in a capacity change signal -- you could define specific
combinations of X and Y to mean "up", "down", and "I don't know", when
specific values aren't available).

---

From: Michael Welzl <[email-masked]>
Date: Fri, 28 Jul 2006 23:01:22 +0200

> mobility or multihoming mechanisms.

I think this is still going in the right direction, but
I would omit the action semantics (like "please reprobe") -
one reason is that we shouldn't restrict future protocol
designers to (thinking of) just this type of action because
the message says so. Another reason is implicitly embedded
in one of the examples you've given: "Available capacity
changed from X to Y, please probe".

A congestion control mechanism always probes - telling
it to probe therefore doesn't make a lot of sense. Right
now, TCP doesn't have/utilize capacity information - but
other congestion control mechanisms have shown that this
type of information can be useful. In any case, if we'd
decide to include capacity notifications, we wouldn't have
a good idea regarding the specific action to recommend.
Thus, it's better to leave it open.

The reason why I said that this is going in the right
direction is that the information should indeed lead to
some kind of action at the transport layer, so thinking
of possible actions is probably the right way to come
up with a useful data set for the messages. And you're
absolutely right about the bad examples ("modulation changed" etc).

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Jul 2006 16:59:10 -0700

>>>     fraction of losses due to corruption.

Is the network giving this to the transport, or the link? The former
seems OK, but the latter not (direct link-transport was - I thought -
the thing that this effort would try to avoid).

>> "Modulation changed" is a bad signal to implement.

It's useful to the network layer, but irrelevant to the transport.
Modulation is a link property, not a path one.

>> mobility or multihoming mechanisms.

Requesting a reprobe is telling the network layer what to do, and
implies that the link knows what the network wants. It seems more useful
to say "link state changed" and let the network decide whether it cares
about that on a path level.

...
> some kind of action at the transport layer, 

or the network layer (or is that out of scope - sorry, I wasn't a the
meeting, so I don't have that 'state').

> so thinking
> up with a useful data set for the messages.

Agreed, but 'just the facts' is the right way to report those messages.
I agree that it's useful to avoid making actionable recommendations, but
definitely useful to consider them as motivation.

IMO, the most interesting question is "why are you saying this", and "is
this the right information to pass between these two layers". The
network can't care that the modulation changed (that's a link/physical
issue), but it can care about what that means (latency changed, error
rate changed, etc.).

Joe

Joe

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Jul 2006 21:14:30 -0400

I am not quite sure if I agree with (or understand)  everything you
said, Joe.  But, ...

> IMO, the most interesting question is "why are you saying this", and
> "is this the right information to pass between these two layers". The

this is basically what I was trying to get at, but put much better.

I see it as somewhat of a balancing act.  We don't want to give
information that another layer just cannot do anything with, but we also
don't want to get too narrow or prescriptive either.

allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Jul 2006 18:23:02 -0700

> don't want to get too narrow or prescriptive either.

Right. I like the idea of "only give info that you think the next layer
can use", but not "tell the next layer what you want it to do". Also,
the information passed ought to be something that makes sense in the
context of the next layer, e.g., tell the network layer about a path
property, not about a link technology, etc.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Sat, 29 Jul 2006 11:14:00 +0200

Hi,

> property, not about a link technology, etc.

this is probably one of the most precise - and concise - descriptions  
of the idea we've been kicking around I've see so far.

Also, we've so far mostly thought about the network/transport  
interface and what additional information could be passed across it  
that would allow some new response mechanisms at the transport layer  
to improve performance. However, the principle of extending  
interfaces in this way - as you've summarized above - can also be  
applied to the link/network and transport/application interface. The  
link/network part is to some degree looked at by mobopts (although  
maybe not following the approach identified above). I'm unaware of  
extensions to the transport/app interface.

Finally, this discussion has mostly talked about moving information  
of a certain kind up the stack in a certain way. Someone (Mark  
Handley?) had pointed out that the reverse direction may also be  
important to look at. Your text above can be read to apply to both  
directions, which is nice.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 31 Jul 2006 15:55:20 +0100

Lars Eggert wrote:
> Also, we've so far mostly thought about the network/transport  interface 
> and what additional information could be passed across it  that would 
> allow some new response mechanisms at the transport layer  to improve 
> performance. However, the principle of extending  interfaces in this way 
> - as you've summarized above - can also be  applied to the link/network 
> and transport/application interface. The  link/network part is to some 
> degree looked at by mobopts (although  maybe not following the approach 
> identified above). I'm unaware of  extensions to the transport/app 
> interface.
> 
> Finally, this discussion has mostly talked about moving information  of 
> a certain kind up the stack in a certain way. Someone (Mark  Handley?) 
> had pointed out that the reverse direction may also be  important to 
> look at. Your text above can be read to apply to both  directions, which 
> is nice.
> 
> Lars

I'm still not yet convinced we understand exactly what the TRANSPORT can 
usefully utilise, and which it can rely upon to make safe decisions.

* One issue that came up time and again in the previuous BoFs - how does 
the tranport entity KNOW the signal is from a node on the path, and how 
much do you wish to continue the idea of "fate-sharing" and "alternate 
paths" - in which it's hard to know if link characteristics really 
impact flows.

* If you know that some of the packets in the flow have been through the 
device, do you trust it? There's DOS opportunities here, and also issues 
of trust between ISPs and Core providers.

* Finally, in the TrigTran BoFs, I also recall some discussion of 
time-scales, what seems like a "timely" event at the physical layer, may 
not be of interest to the transport layer (working on a timescale of 
several Path RTTs).

I and others have said these sorts of things several times (sorry), and 
it would be really good to capture exactly which signals are 
trust-worthy and useful to a transport entity.

In the other direction: What are the things the transport enities could 
tell the link/phy? and how will it know to use these? WE already have 
QoS and QS/XCP type signals, what are the additional features desired?

I think if we understand the usefulness, we can make progress. One 
example of "something that changed" is advice that the link RTT is large 
(or has just become large) could be  useful. For this, it's wise to make 
transport protocols that don't rely on exact timing (which is good 
practice and we're doing this), so simply bumping up the stored RTT 
seems plausible (and then letting the transport reprobe to confirm 
this). I think Mark (?) queried whether we need to be exact about what 
changed has... could it be that any path change would sensibly lead to 
the same sort of re-probe to confirm RTT, MTU, etc?

Gorry