On Mon, 8 Jul 2002, Joe Touch wrote:
> Lloyd Wood wrote:
> > On Fri, 5 Jul 2002, Joe Touch wrote:
> >>
> >>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.
>
> That's not IP state. That's link state.
that's semantics.
> 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.
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.
> >>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).
> >
> > 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?
>
> That sort of info is a MIB. It isn't passed via IP, so much as
> 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
> noted above.
It could be stored in the implementation.
> > (Fortunately, routers that know about links and know about routing
> > tables can use the information regardless if it's useful.)
>
> 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?
> If this is all about arguing for a MIB, why? Just do it.
>
> > 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.)
>
> 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.
> 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?
No, and I never suggested that.
> 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
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.
> None of this is IP.
>
> Joe
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Tue Jul 09 2002 - 07:58:17 EDT