Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2002 13:04:16 -0700

Phil Neumiller wrote:
> I am sorry about that "sand" comment.  It seems the arguments quickly get circuitous.  What we
> are suggesting is something really subtle.  
> 
> A).  IP needs to create a standard interface method on its unspecified bottom half.
> B).  It already has one on the top, namely sockets.
> 
> This is quite different than saying, all L2s must do this or that.  What we want is a mechanism to 
> pass L2 information in a standard way up to and through the IP stack.

Given that IP is stateless and connectionless, what would IP do with any 
particular information it gets?

There is no way to push information through a stateless system into a 
stateful one (e.g., TCP, or to application layers, e.g., routing 
protocols or user applications that are carried as data inside transport 
protocols).

The exceptions would be MPLS (as a stateful layer below IP, which could 
do something with such info). The state of mobile IP is essentially 
application layer, for all intents, to the IP layer.

> What is so complicated about this?

See above.

Joe

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 7 Jul 2002 20:26:44 +0100 (BST)

On Fri, 5 Jul 2002, Joe Touch wrote:

> Phil Neumiller wrote:
> > I am sorry about that "sand" comment.  It seems the arguments
> > quickly get circuitous.  What we are suggesting is something
> > really subtle.
> >
> > A).  IP needs to create a standard interface method on its
> > unspecified bottom half. B).  It already has one on the top,
> > namely sockets.

sockets isnt' a standard.
streams isn't a standard.

> > This is quite different than saying, all L2s must do this or that.
> > What we want is a mechanism to pass L2 information in a standard
> > way up to and through the IP stack.
>
> Given that IP is stateless and connectionless,

As if.

A link interface is allocated an IP address and mask. That's state.
The link interface is either up or down. That's your immediate
connection to the subnet.

(and ICMP is all about telling others about your IP state.)

> what would IP do with any particular information it gets?

Pass it on.

> protocols or user applications that are carried as data inside transport

You're saying that if a link goes down there's no way to tell routing
about it, because IP gets in the way and routing is above IP?
(Fortunately, routers that know about links and know about routing
tables can use the information regardless if it's useful.)

When the link on a host goes down, will the TCP stack continue to
accept data from the application even though it can't be sent? (Phil's
kick-TCP-when-the-link-comes-up also springs to mind.)

L.

> > What is so complicated about this?

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: James Carlson <[email-masked]>
Date: Sun, 7 Jul 2002 17:10:15 -0400

> streams isn't a standard.

That's not quite the case.  Both are standardized in the SUSv2.
Sockets is in the XNS:

http://www.opengroup.org/pubs/catalog/c808.htm

and the STREAMS user-level interface is in XSH and XBD, which are also
IEEE Std 1003.1-2001 (POSIX).

The kernel bits are also standardized.  DLPIv2 is C811:

http://www.opengroup.org/pubs/catalog/c811.htm

TPI is C810:

http://www.opengroup.org/pubs/catalog/c810.htm

and, of course, the SVID.

Just because something isn't part of the IETF doesn't make it
"non-standard."  Just because something *might* need to be
standardized does *not* mean that it needs to be done within the IETF.

There are many groups that are equipped to deal with standardizing
software interfaces for various platforms.  If you're interested in
contributing to that work, then I do recommend that you join such a
group.  The IETF isn't the 'droid you're looking for.

> connection to the subnet.

Agreed.  However, the state essentially disappears above IP.  A
properly implemented TCP neither knows nor cares about the state of
interfaces.  All it cares about is sending and receiving segments.
These somehow either make their way to a remote destination or are
lost.

In particular, if you rip up TCP connections merely because an IP
interface goes down, then that's a rather horrific bug.  TCP is
*supposed* to survive re-routes, whether in the local system or in an
intermediate router.

> > what would IP do with any particular information it gets?

To whom?  Such changes affect the IP forwarding ("routing") table in
most cases, and need to be communicated to routing protocols.  If you
do QoS, then changes might affect any int-serv reservations you have,
but that's really just a special case of a routing protocol.

Such a change should *not* touch any transports or applications,
however.

> tables can use the information regardless if it's useful.)

Agreed.  Only routing can care.

> kick-TCP-when-the-link-comes-up also springs to mind.)

In short: *YES!*

There are many reasons this is true.  The link it was once using might
not be the only way to get to the desired destination.  Even if it's
the only way to get there, the link may still come back soon enough to
recover.

If this weren't the case, then wouldn't you also want to kill off TCP
sessions when you see a single ICMP Destination Unreachable?  What's
the difference between a link that flaps on an intermediate bottleneck
router versus one that flaps on the local host?

If you are stuck using a stack that does otherwise, then that stack is
just plain broken.  You probably should upgrade to one that works
right.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 8 Jul 2002 13:25:51 +0100 (BST)

> and, of course, the SVID.

Right. You've cited several different standards from several different
standards organisations. That's not the single 'standard interface
method on the top' that Phil was alluding to, because there is no such
one method.

(Getting a standards body to announce that a specification is fixed
 and documented as a standard doesn't make it a universal standard.
 All it means is that you've found a (self-appointed?) standards body
 that will accept it and provide change control.)

> interfaces.

I don't think that is reasonable. (And the whole pseudo-header design
shows the lack of clear separation between TCP and IP. They're in the
same stack, dammit)

> All it cares about is sending and receiving segments.

If you're an endhost with only one link out (on a stick), ripping up
the TCP connections may be a reasonable thing to do. Why wait for
applications to time out and complain about something not being
reachable when they could simply learn 'no link available' and then
decide whether to communicate this to the user (a browser making http
requests, say) and decide whether to tear down their tcp sessions? The
decision to (half-)close TCP connections is an application decision,
so the application would need to know to make that decision.

(Not that this is IETF work, being an endhost interface thing.
However, any learned link characteristics that could be fed into a
smart TCP algorithm - a known long-delay link because you're at the
immediate end of a satellite hop affecting initial window size and
RTO, say - would be affected by that link going down. That's arguably
IETF work.)

> Such a change should *not* touch any transports or applications,

see above.

> the only way to get there, the link may still come back soon enough to

But can the application learn that passing data to TCP might not be
the best thing to do if connectivity is not there? TCP was designed
for an always-connected world, not a world of intermittent link
connectivity.

> sessions when you see a single ICMP Destination Unreachable?

I think you can trust local link interface state more than you can
trust ICMP messages generated remotely, and that the local TCP should
know which local interface(s), if any, that it's going out of.

> What's

Quite a lot. You *know* the local interface is flapping. If IP can see
the local interface is flapping, then L2 'debounce' timers have
already given up on it, and you can use that information.

L.

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Jul 2002 16:10:24 -0700

> connection to the subnet.

That's not IP state. That's link state. There's nothing IN IP that knows 
about that assignment.

> (and ICMP is all about telling others about your IP state.)

ICMP is to indicate errors, but not stateful ones. The error can easily 
have disappeared, or the message can be deleted.

> about it, because IP gets in the way and routing is above IP?

That sort of info is a MIB. It isn't passed via IP, so much as 
transparently through it.

There is no place _IN_ IP to store the "this link is down" state, as 
noted above.

> tables can use the information regardless if it's useful.)

Routers know out-of-band info about links, communicated as data already. 
If this is all about arguing for a MIB, why? Just do it.

> kick-TCP-when-the-link-comes-up also springs to mind.)

A link on a host going down isn't enough; the host might be multihomed, 
at which point routing comes into play. And where's that routing - on 
the host, or a few hops down?

You really want to kick TCP whem a phone line 100 miles away goes down, 
even if it isn't necessarily connected to your machine? That's what 
routing is for.

----

What appears to be desired here is:

	a realtime MIB for link state
	a routing protocol that reads and reacts to the MIBs on
	microsecond timescales

None of this is IP.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 9 Jul 2002 13:06:18 +0100 (BST)

On Mon, 8 Jul 2002, Joe Touch wrote:

> That's not IP state. That's link state.

that's semantics.

> There's nothing IN IP that knows  about that assignment.
>

ICMP messages are relied on to build state (e.g. path mtu discovery),
and therefore cannot be regarded as stateless. Otherwise path mtu
discovery is completely unjustifiable.

> transparently through it.

A MIB can only be useful for reporting to remote hosts.
Implementations generally do not use MIBs to talk to themselves.
(Efficient implementations certainly wouldn't.)

> There is no place _IN_ IP to store the "this link is down" state, as

It could be stored in the implementation.

> Routers know out-of-band info about links, communicated as data already.

and not as a MIB. My question is: why are endhost implementations so
STUPID compared to routers in this respect, in not even knowing what
they're immediately connected to and whether it's there or not? That
end-to-end argument corollary about putting complexity at the edges
and keeping the midpoints simple just doesn't get borne out in
practice, does it?

> A link on a host going down isn't enough; the host might be multihomed,

The host should know whether it's multihomed or not; it should know
what it's immediately connected to. If it's not multihomed and e.g.
the AAA server at the other end of the PPPoE line goes down and takes
your phoneline's TCP dialtone with it - the immediate link is down and
your stack is offline. You can inform the apps.

> even if it isn't necessarily connected to your machine?

No, and I never suggested that.

> That's what routing is for.
>
> ----
>

1) MIBs aren't realtime. Not so sure they're desirable, either.
2) local implementations don't use MIBs to talk to themselves.
   An endhost using a MIB to tell itself about its own link
   interfaces? I don't think so.

L.

---

From: James Carlson <[email-masked]>
Date: Tue, 9 Jul 2002 08:11:54 -0400

> your stack is offline. You can inform the apps.

How does the stack determine that the link is down because, for
instance, the peer router is rebooting, and that it will be back in a
few seconds?  Should my ssh session and all of my redirected X11
windows be blown out of existence because the router at the other end
of that DSL link bounces?

I still don't see how link unavailablity is *reasonably* translated
into TCP connection sniping -- particularly as a default policy.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 9 Jul 2002 13:21:25 +0100 (BST)

> of that DSL link bounces?

That's a decision for ssh or the Xserver to take as applications.

> into TCP connection sniping -- particularly as a default policy.

What default policy? Provide the information to be used on a
case-by-case basis, that's all.

L.

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 9 Jul 2002 09:45:08 -0400

> for an always-connected world, not a world of intermittent link

Bingo!  and one of the first useful steps towards the design of transport
protocols that are more useful for wireless; is the sort of triggers we 
have been talking about here.  QoS will never quite work right between
wireless router hops (especially the rapidly changing type) without this
IMO.

Thanks,

Phil

---

From: Aaron Falk <[email-masked]>
Date: Tue, 09 Jul 2002 13:38:00 -0700

--Phil Neumiller wrote:

> and one of the first useful steps towards the design of transport
> protocols that are more useful for wireless

You don't mean Transport layer protocols (as in 
end-to-end-replace-all-the-stacks-in-the-Internet), do you?

--aaron

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Jul 2002 14:26:36 -0700

Lloyd Wood wrote:

> they're immediately connected to and whether it's there or not?

Hosts that run routing software aren't. If you have a multihomed host, 
run routing on that host. Embed the functionality of a router in the 
endpoint, and call it a day - we did 5 years ago:

  "Dynamic Host Routing for Production Use of Developmental Networks"
J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292. 
(www.isi.edu/touch/pubs/)

 > That

The end and middle are a matter of perspective; you want the middle 
(other links) to configure your endpoint (a router inside the end 
system, which is also your host). This isn't new, and it isn't a 
conflict with E2E either.

> 1) MIBs aren't realtime. Not so sure they're desirable, either.

IP isn't realtime either.

>    interfaces? I don't think so.

How do routers do it? Why is this new?

Joe

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 9 Jul 2002 17:20:22 -0400

Hi Aaron,

Quicky Answer:  No.

Long  winded answer:

Protocols for the Internet are not to be replaced but MAY surely be improved for
wireless devices right?  If you think so, you may agree some of the points A-F 
listed below.

If you don't agree; can you explain to me how QoS for wired/wireless links is going
to work properly without L2 trigger events providing feedback to/through IP?  
How about fast and seamless handovers for wireless devices to from other wired
and wireless devices.

Some points in order of dimishing IETF support (I think....)

A).  Wireless access to the global Internet is only going to grow (by any stretch of the 
       imagination). [most IETFrs will buy this]
B).  The physics of wireless links is different from that of fixed links.  It is different 
       enough to warrant at least some specialized treatment. [probably lose most the pilc 
       crowd here].
C).  To operate with satisfactory performance, in a variety of wireless settings, IP
       requires some fundamental improvement in implementation AND in standardization
       (probably spread out over quite a few SDOs)
D).  IP-over-everything should be qualified as: IP-over-everything wired (at least with
       the way things are now).
E).  TCP is currently broken for wireless (I know there is work on going).  UDP is not
       too much help.  SCTP improves certain things.  L2 triggers are a stepping stone
       toward fixing some of the problems by giving transport protocols visibility into
       fast changing L2 behavior, like link quality changes, link drops, etc.
F).  Wireless L2s share much commonality  with each other,  but not as much with fixed/
       wired links with respect to their real time behavior.
G).  L2 triggers are fundamental to fast/seamless/smooth/fluffy/soft IP layer handoffs.

Best regards,

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 9 Jul 2002 23:07:01 +0100 (BST)

On Tue, 9 Jul 2002, Joe Touch wrote:

> Hosts that run routing software aren't.

They are, because the routing software doesn't talk to the endhost
applications. No real integration or communication between the two.

> If you have a multihomed host,

As for calling it a day - I see you couldn't maintain a TCP connection
with it since you didn't have control of the source address the SunOS
stack set - p5 - and you end with a plea for static loopback
addresses, as found in all good router software for years, to fix
this. No real integration.

If you simply run routing software on the host the host's applications
still can't know about local link connectivity, and they won't know
about the routing software either.

> IP isn't realtime either.

Why not?

> How do routers do it?

A simple function call to find out would suffice. No MIB. Minimal
running code. But routers are integrated beasts, while typical
endhosts aren't.

> Why is this new?

That endhost stacks lack functionality is hardly a novel observation.

L.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 9 Jul 2002 16:37:21 -0600 (MDT)

> From: Lloyd Wood <[email-masked]>

> ...

Again, why can't the host's applications that care open a routing 
socket and to hear all about interfaces coming and going?

Or is all the world a Solaris box?

> ...

What are the decades old getifaddrs() and the merely decade old
routing sockets, chopped liver?

Vernon Schryver    [email-masked]

---

From: Aaron Falk <[email-masked]>
Date: Tue, 9 Jul 2002 15:59:25 -0700

On Tue, Jul 09, 2002 at 05:20:22PM -0400, Phil Neumiller wrote:
> wireless devices right?  

If it's not backwards compatible with the existing protocols, it
sounds like a replacement.  I think specific proposals are needed to
discuss this point further.

> How about fast and seamless handovers for wireless devices to from other wired

Well, I'm in the camp that needs to be convinced that fast mobility
isn't better handled at the link layer.  

>        enough to warrant at least some specialized treatment.

My understanding is that link technologies can overcome many of the
physical limitations of wireless networks (e.g., BER).  We've looked
at this in detail in draft-ietf-pilc-link-design-11.txt.  The place
where things seem to break down is where handoffs are occurring
between different link layer networks (e.g., 3g to 802.11).  However,
this isn't a limitation of the physics of wireless networks.  

On the other hand, if you are talking about the fact that your big ftp
stalls when you go into a tunnel with your wireless handheld.  Well,
do you really think this is big enough problem to rearchitect the
TCP/IP stack?  The Internet was design to support subnet heterogeneity
and specifically avoided optimizing for specific technologies.
(http://www.isi.edu/newarch/DOCUMENTS/rtb.IPAM.mar02.pdf has a
discussion of the design principles of the Internet that you might
find interesting.)  Basically, the "specialized treatment" you suggest
is best applied locally, i.e., at the link.

> E).  TCP is currently broken for wireless (I know there is work on
  going).

I find this statement surprising.  "Broken" is a very strong word.
Where is this documented?  We've been working on TCP performance over
wireless networks in PILC for two (three?) years now and this is the first time
I've heard it described as broken.  Perhaps your definition of broken
(& wireless, for that matter) is different from mine.  Anyways,
references would help.  

Regards, 

--aaron

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 10 Jul 2002 00:06:05 +0100 (BST)

> Or is all the world a Solaris box?

interfaces going up/down is not the same as interfaces coming or
going.

> routing sockets, chopped liver?

And what gets to mark the interface as up or down?

L.

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Jul 2002 16:38:09 -0700

> applications. No real integration or communication between the two.

OK - so build a framework for that; that's an API, not a protocol, and 
not necessarily in scope for the IETF (it's not even socket level).

> stack set

Yup. That's been fixed in some OS's for a while, and won't go away with 
any other solution either.

> - p5 - and you end with a plea for static loopback
> this. 

Yup - they're available now. It has been 5 years.

>>IP isn't realtime either. 

OK - so if you're on that tack too, please send comments to the IAB. 
This is definitely outside the scope of a single WG.

> A simple function call to find out would suffice.

Fine. Implement one. Why standardize it?

Joe

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 9 Jul 2002 17:46:36 -0600 (MDT)

> interfaces going up/down is not the same as interfaces coming or

What's the substantive difference?  
Shouldn't a good L2 driver twiddle an IFF_ON or IFF_RUNNING bit when
bad things happen, and so signal routing socket listeners?
I think reasonable `routed` implementations notice when an Ethernet
cable is disconnencted.  What's the difference between that case
and a datagram application on a mobile phone suffering some sort of 
fading or dropped handoff?

Granted, I'm playing a little loose with the details.  In the common
BSD `routed` code, the daemon notices the error counts that result
from a disconnected Ethernet cable or a kaput FDDI ring and marks the
interface down.  UDP applications then start getting errnos equivalent
to ICMP Unreachables.  TCP applications start their normal 90 to 300
second timeouts, if they send any traffic.  I don't know about telephony
appliations, but UDP conferencing applications tend to have enough
regular traffic to notice a dead link.  However, from what I've seen,
they tend follow the primary rule of programming and ignore errors
they can't handle.

> And what gets to mark the interface as up or down?

Why not the L2 driver?

I've forgotten more than just the details, but I think I remember
writing BSD-style FDDI drivers that downed the interface on bad
situations such as stuck-BEACONing.

I fear this discussion has again wandered into the weeds of hypothenticals
far from practice.  The separateness of IP from L2 is more evident in
cloud diagrams than in code.  For that matter, the distance between
TCP and L2 is larger in theory than in practice, at least if you've
ever made a system page flip or use hardare for the TCP and UDP
checksums.  For example how does TCP know whether compute checksums
when some of the L2 interfaces on a system has checksum hardware and
some doesn't?  Teaching a system to page flip tends to make the L2 driver
want to know about stuff in the application stratosphere above TCP or UDP.

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 10 Jul 2002 12:07:13 +0100 (BST)

On Tue, 9 Jul 2002, Vernon Schryver wrote:

> second timeouts, if they send any traffic.

Exactly. having e.g. a daemon conclude that or ifconfig mark the
interface as down from secondary evidence is not the same as having
the L2 driver learn about from hardware and do the same thing
reliably, but the former is more common in endhosts than the latter.

(Boot up a redhat-using laptop sans network connection and wait 90
seconds for it realise that there isn't going to be any network
traffic. In a sanely engineered world, not having anything plugged in
to the ethernet port should be the instant dead giveaway.)

L.

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 10 Jul 2002 12:43:32 +0100 (BST)

> This is definitely outside the scope of a single WG.

The VoIP phone on my desk isn't realtime?

> Fine. Implement one. Why standardize it?

Taken from an earlier email in this thread:

[..]
[..]

L.

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jul 2002 08:09:07 -0400

> reliably, but the former is more common in endhosts than the latter.

Agreed.  For what it's worth, I work for an endhost vendor that does
indeed have the latter on some interfaces.  It's certainly not as
common a feature as one might like, but it's not wholly unknown.

In any event, this isn't something the IETF can fix.  The IETF writes
documents that describe protocols.  It really isn't in a position to
force vendors to write any particular code -- including code that
works the way some particular users would like to see it work -- and
writing documents doesn't solve the problem that vendors don't always
implement features that users want.

Yes, when possible and practical, L2 interfaces ought to tear
themselves down when they become unusable so that they don't represent
black holes to the rest of the IP system.  L2 interfaces ought to
interface with management software such that alarms get delivered in a
reasonable manner and diagnostics can be run to pinpoint problems.
This is all part of the existing body of common networking design
knowledge.  The fact that these things often aren't the case, even
when the solutions are well known and the L2 mechanisms are part of
the existing (mostly non-IETF) standards, points to holes in the
implemented feature sets (and original requirements), not necessarily
a lack of new protocols.

In other words, if the vendors aren't implementing the existing things
that are already known, why would adding a *new* thing to the long
list of standards make the situation any better?  I think we need to
fail collectively after having *tried* the solutions we already know
about before we set off to create new solutions, and I don't see that
this is the situation.

> to the ethernet port should be the instant dead giveaway.)

That's an even easier fix.  You have the source.  Nuke the IFF_RUNNING
bit on carrier loss.

Be prepared to be incompatible with a wide array of equipment after
you've done that, including (probably) switches with long spanning
tree timeouts.

(And note also that the POSIX standards require you to fail a
connect() call immediately when the requested destination isn't in the
local forwarding table.  Thus, ripping up the IP interface on failure
is enough by way of notification to new connection attempts.  Of
course, if that interface is broken, you have other problems.)

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 10 Jul 2002 07:45:09 -0600 (MDT)

> reliably, but the former is more common in endhosts than the latter.

That you trimmed these words of my strikes me as an quoting out of
context of what I said:

] I've forgotten more than just the details, but I think I remember
] writing BSD-style FDDI drivers that downed the interface on bad
] situations such as stuck-BEACONing. 

If I recall correctly, that had nothing to do with daemons, because you
deal with FDDI problems such stuck-BEACONing in the driver and don't
have any daemons for help (or at least that was the case in my code).

> to the ethernet port should be the instant dead giveaway.)

90 seconds is far longer than necessary, particularly when you are
talking about booting up instead of a disconnection of a working link.
I'm sorry RedHat is so slow, but since the overall topic is about L2s
that were present but break instead of L2s that never existed, since
I wasn't talking about Linux, and since the common BSD `routed` does
not run on Linux (for lack of 4.4BSD-Lite "routing sockets"), I don't
see its relevance.

On the other hand even 90 seconds is faster you can reasonably hope
to do anything with an existing TCP/IP connection no matter how many
L2 triggers you have, because no L2 trigger on your laptop is going
affect the far end of a TCP connection.

I think you are continuing to make much the same error of circular
reasoning as the people who argue that TCP must be thrown out, because
mobile wireless modems or G3 phones are completely different than
anything that has come before.  You are assuming it is impossible for
a L2 driver to do as I said and diddle the IFF_RUNNING or IFF_ON bits
in order to reach your conclusion, just as they assume that TCP never
before ran over modems slower than 9600 bit/sec with large error rates
or long drop-outs (e.g. the effects of "call waiting" or needing to
hang-up and redial).

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 10 Jul 2002 15:17:40 +0100 (BST)

> That you trimmed these words of my strikes me as an quoting out of

Hardly. Note the discussion of former and latter cases above.

> have any daemons for help (or at least that was the case in my code).

Note the discussion of former and latter cases above.  I imagine that
that would be an example of the latter case, but if you can't be
certain of it I'm certainly not.

> that were present but break instead of L2s that never existed,

not much difference.

> since I wasn't talking about Linux, and since the common BSD
> `routed` does not run on Linux (for lack of 4.4BSD-Lite "routing
> sockets"), I don't see its relevance.

(Linux has netlink these days.)

Right. routing sockets aren't common, so may as well be chopped liver.
You're just not being relevant...

> affect the far end of a TCP connection.

It doesn't need to. It only needs to affect the near end, so that
it's known that sending out a packet and waiting for a response is a
waste of time and the application(s) can go do something else instead.

An analogy: If you're gagged, don't waste your breath saying 'Mppph!
Mppph!' and waiting for people to do what you say. Suppress it until
the gag comes off and spend the time thinking about a compelling plea
for your life instead.

> in order to reach your conclusion

latter case. latter case. latter case.

> just as they assume that TCP never

diddling those bits alone may not be sufficient, for reasons James
points out. It's not widespread practice, and thanks to the rest of
the OS and related assumptions it might not have the desired effect.

You appear to have mistaken me for some 'wireless QoS with fluffy
handovers' advocate; the number of people contributing to this thread
is greater than "you" and "not you".

L.

pilc: a high-school debating society in limbo.
      a bunch of protoRFCs currently in limbo.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 10 Jul 2002 08:41:22 -0600 (MDT)

> the gag comes off and spend the time thinking about a compelling plea

That makes no sense to me in this context, because the gag of
a tunnel or other radio problem afflicts both parties for at least
some applications that have been mentioned (e.g. VoIP).
Your "not wasting your breath" also can't be a matter of turning off the
radio to save power or something similar, at least not in this context,
because even if appropriate, that's nothing to do the application.

Internet application hiccups of seconds to 10s of seconds are not
exactly new.  I'm at a loss to think of a real application that might
want to do besides blink a red "trouble" light while patiently waiting
for the timers in TCP or its own UDP using code to repeatedly say
"Mppph Mppph" until giving up or the gag disappears.  Maybe that lack
of practical interest is why the various application-L2 interfaces
have not shaken down to 1 standard plus the embrace-and-extend varient
as has happened with the rest of the network API.  (Does anyone still
really support STREAMS, not to mention "QIOs" and other stuff?)

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jul 2002 11:09:31 -0400

> Right. routing sockets aren't common, so may as well be chopped liver.

Even if that were true (and I certainly don't think that it is), how
could internal interface details be relevant here?

The IETF writes Internet protocols, not internal APIs.  There are
other groups that are focussed on that problem.

Besides, if you're really using a broken system that doesn't have
routing sockets or any other usable interfaces, then why not just tell
the vendor that you're switching to a system that *does* support the
interfaces you need?  I happen to have direct knowledge of at least
one such system that's available.  ;-}

> waste of time and the application(s) can go do something else instead.

Isn't it a waste of time for the remote end of the communication to
send data as well?  Unless this is a fixed L2 connection between the
two endpoints, how does *it* know about the problem?

Why is it an interesting optimization to code for the special case
where one end of the TCP connection happens to be the one IP node that
is directly attached to a flakey L2?  What happens when there's a
firewall/router used to terminate that L2 instead?  Don't we just fall
back to the ICMP Destination Unreachable timeout case instead?

> the gag comes off and spend the time thinking about a compelling plea

Of course, if you're a computer, it does you no harm at all
periodically to say "Mppph" in the hope that one time it will work.
Computers seem to have a staggering amount of breath.

> the OS and related assumptions it might not have the desired effect.

I don't agree with much of that at all.  Diddling those bits works for
*most* of the interesting cases.  In any event, what we're talking
about here is internal system architecture, not protocols.

For the cases where it *doesn't* work, some very L2-specific work
needs to go on, and (clearly) these need to be documented in detail
before any work directed at solving them can start.

> really support STREAMS, not to mention "QIOs" and other stuff?)

Yes, of course, SVID-compliant systems still support STREAMS.  :-/

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 15 Jul 2002 14:39:29 +0100 (BST)

On Wed, 10 Jul 2002, Vernon Schryver wrote:

> a tunnel or other radio problem afflicts both parties

No, it does not. It's an asymmetric world (the tunnel may be
multipoint), and the other party may not be directly on the other end
of the link. For bidirectional links, a single link up/down suffices;
for radio where link and channel collapse together, things
get more complex - you've still got the channel, but is it useful?

> for at least

It's a matter of the brain (application) recognising the futility of
going Mmmph.

TCP congestion control (vocal chords?) is about sending out in a
controlled manner to avoid congestion collapse (running out of breath,
leaving gaps for other person to interrupt. Yes, I know I've
stretched the analogy.)

Application control should be about not queueing up stuff to be sent
that can't be sent in a reasonable timeframe required by the
application. You're just filling up buffers for no good reason.

> exactly new.

more's the pity.

> I'm at a loss to think of a real application that might
> "Mppph Mppph" until giving up or the gag disappears.

blink a red trouble light and give more meaningful error messages to
the user is a valid use. (The 'Can't find home.netscape.com'
maybe-your-dns-or-proxy-is-messed-up message always struck me as a bad
example of same.)

An online realtime multiplayer game might take local control of the
players' representations with the object of getting them all
out of sight of each other as quickly as possible to ease syncing up
play when the connection comes back.

L.

> Maybe that lack