Re: [DNA-BOF] Re: Sending while DNA is in progress...

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Bernard,

Bernard Aboba wrote:
>>Even if the ND cache or transmission state is latent, packets could
>>still be sent for DNA purposes of course, but we'd have to examine
>>whether other traffic would be paused, sent or discarded (for example,
>>if it takes a long time to do DNA, then VoIP packets are better
>>dropped).
> 
> 
> It has been pointed out to me that packets already in the queue aren't
> salvagable if the host has changed subnets.  Typically the choice is
> either to send them or discard them -- you can't go back and change the
> headers after DNA completes, since that might require resegmentation.

Indeed, waiting until the packets are in the queue for transmission
doesn't help.

If we're on the same IP subnet though (so our packets are topologically
correct), the pause adds delay, but if we send packets which are going
to be ingress filtered by the Access Router, this wastes power
resources.

This trade off may be worth looking at for power sensitive devices.

> If the host remains on the same subnet, the packets can and should be
> sent. If the host has changed subnets, then no packets in the queue can be
> delivered successfully.
> 
> As a result, continuing to send enqueued packets under the assumption
> that the subnet remains the same has no downside, though it might make
> sense to suspend the addition of packets to the send queue, pending completion
> of DNA, so that they could be sure to acquire the correct headers.
> Latency sensitive applications such as VOIP might be an exception to this.
> 

Pausing in output queue additions may be a good way to ensure
that we don't empty TCP windows with packets going out with
the wrong addresses...

I'm not sure whether the distinction between Datagram (especially
Real-Time datagram) and Stream services can be made in the basic
solution (except as a MAY), although the choice of sending packets
before DNA would probably have the same strength.

Greg