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