Hi Bob,
> Fred,
>
> At 00:01 05/01/2007, Templin, Fred L wrote:
> > > Couldn't use of the coding scheme be negotiated between tunnel
> >endpoints
> > > for all tunnelled packets carrying a specific src-dest
> address pair?
> >
> >This might work for persistent configured tunnels that are
> >established through some initial negotiation phase, but
> >might not be so practical for automatic tunnels or tunnels
> >that are short-lived and/or only carry a small number of
> >packets. It is also possible that this AF scheme may be used
> >by IPv4 packetization layers other than tunnels and may even
> >supplement or replace RFC791 IPv4 fragmentation.
>
> If we're expecting to be able to fire a few tunnelled packets
> at a router
> and get it to decapsulate and re-assemble them to your spec,
> we either:
> - have to know that all routers implement your spec (which we
> already know
> they don't)
> - or somehow negotiate its capabilities with it first,
> - or something else tells you it's capable (e.g. you are
> configured to
> already know).
> The only case for using a per-packet flag would be if, within
> the same
> tunnel, some packets used your scheme and others didn't.
In terms of initial negotiations, the encapsulator can
send the first packet out according to the AF scheme with
the Probe ("P") bit set in at least one segment and cache
the original packet. If a probe response comes back, the
encapsulator discovers that the decapsulator implements
the scheme and can continue to use AF for subsequent
packets. Otherwise, the encapsulator can use an algorithm
such as:
if(cached_packet_len <= 1280) {
do not set the DF bit
send packet
} else {
drop packet
send ICMPv6 "packet too big" to source
}
and can then send all subsequent packets under the assumption
that this decapsulator does not implement AF.
> If you don't absolutely need to use the last available bit in
> the IPv4
> header, surely you are morely likely to get the proposal
> through without
> using it.
>
> > From what I can tell one question comes down to whether we can
> >expect to see IPv6-in-IPv4 tunnels deployed on a wide scale and
> >on a long-term basis in the Internet? If so, we will need tunnel
> >MTU assurance that provides robustness and efficiency over
> >arbitrary Internet paths.
>
> Yes, we'll need a robust solution, but initial capability
> negotiation is no
> less robust than per packet negotiation if you don't need per packet
> negotiation.
>
> >Another question comes to whether such an AF scheme could
> >supplement or replace RFC791 IPv4 fragmentation (along with
> >its myriad issues that are well documented) even for
> >non-tunnel applications.
>
> Even if it replaces RFC791, there will still be a legacy.
"Replace" is something I ought not to have said, and I want
to apologize for this and any other presumptuous tones my
previous messages may have taken. We are talking about *the*
Internet Protocol here, and there should be no presumption
that we now somehow have a way of obsoleting a core function
of IP. A better term to have used than supplement/replace/avoid
etc. may have been "coexist".
> > > I'm not quite making that assumption. I'm saying re-assembly
> > > over shorter gaps should take priority over longer gaps, so
> > > re-assembly over longer gaps should be deferred for a while.
> >
> >That's fine, but my intuition is that applications and
> >transports are not very tolerant of grossly reordered packets
> >and some may prefer to receive partial data (e.g. using UDPlite)
> >over data that arrives too late.
>
> Surely that can be implementation dependent. There's no need
> to mandate
> that long gaps are thrown away if its possible to solve the
> problem by
> merely deferring them behind short gaps.
I also prefer successful reassembly, and don't mean to mandate
any particular behavior. But I also believe (without proof)
that deferred reassembly for grossly-reorderd packets within
the same flow may be little/no different than declaring the
packets as loss after a reasonable timeout window.
Thanks - Fred
[EMAIL PROTECTED]
> Cheers
>
>
> Bob
>
>
> ______________________________________________________________
> ______________
> Notice: This contribution is the personal view of the author
> and does not
> necessarily reflect the technical nor commercial direction of BT plc.
> ______________________________________________________________
> ______________
> Bob Briscoe, Networks Research
> Centre, BT Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
> +44 1473 645196
>
>
>
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
