Hello Vicky,
Wouldn't the PktSource still be a data element even if it is an Address
Block TLV?
I agree with you that sending an RERR upon reception of an undeliverable
data
packet SHOULD inhibit sending of new RERR packets for a little while for the
same PktSource/destination pair.
Generally, the reason for not multicasting is to avoid bothering otherwise
quiescent neighbors. But this could be a selectable behavior. Notably, when
PktSource is included, a lot of neighbors might end up forwarding separate
RERR messages back to PktSource, so multicast could be burdensome.
Storing MAC addresses during packet forwarding might have a big impact
on throughput. Stan would know better, but I think that routers hate doing
that sort of thing.
I hope the above statements can be matched with the discussion below.
Regards,
Charlie P.
On 4/30/2015 7:20 AM, Victoria Mercieca wrote:
Hi all,
Still catching up on emails:
On Mon, Apr 27, 2015 at 9:07 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Lotte,
If there are addresses in the RERR and they aren't otherwise marked,
they should certainly be Unreachable addresses. I don't see why not.
Would you require the same for every other sort of TLV that might be
applied to addresses, in addition to SeqNum?
This would be an unmitigated disaster.
I'd rather prohibit SeqNum for all RERR messages and forget about the
small improvement in correctness, than require SeqNum for all RERR
messages.
Regards,
Charlie P.
So to sum up all recent emails on this:
PktSource should go in the AddressBlock since it is an IP address. If we do this, we should change the PktSource TLV to be an AddressBlockTLV, and use it to mark which address in AddressBlock is the PktSource. For now, we leave all others unmarked, and let MANET complain at a later date (...and maybe have to give in at some point in the future and put one extra TLV in to apply to all other addresses except for PktSource, which signals that they are unreachable addresses).
To duplicate from the other thread ("RFC5444 tables"), the changes this involves are:
In the IANA section, we can remove PktSource from the Message TLV
section, define it as an address block TLV, Type 14 (TBD), Length
0 (because it wont need to contain a value) and reference back to
section on RERR messages.
In the RFC5444 section we'd move PktSource into the address block,
and in the address block TLV block, we'd have a section for
PktSource, where we associate the PktSource TLV, with no value or
extension type.
In the RERR section, PktSource wont be a data element. I can
update that section to have PktSource added to the AddressList.
The text will need a bit of work in the
generation/reception/regeneration sections.
Shall I go ahead and do this?
I think its fairly sensible to assume that addresses in a RERR are unreachable addresses, unless a TLV is associated to signal that it is a different type of address.
Looking at the other comments in this thread:
* What happens if we get another packet with the same sourceThat would mean that the previous RERR didn't "work", so maybe
and destination - do we send a RERR every time?
it's a good idea to
allow RERR to go out again.
I was thinking, what if a stream of packets was in progress, we send a RERR for the first one, but more are already coming through the network, and before the RERR reaches the sender, it's already sent many more packets for the same destination... Do we resend the RERR for every packet we cant deliver? Or should we try to notice its the same source and destination and refrain from duplicating a RERR, at least for a certain length of time?
If SeqNum is optional, I'd urge us to add a rule in the “RFC 5444* When creating the RERR, MetricType might come from someYes, definitely SeqNum should be optional.
type of service value in the packet, but SeqNum and
PrefixLength are unlikely to be known (unless we can match
it to an invalid route) - SeqNum doesn't look optional
though, should we include SeqNum zero? Will it be assumed
to be zero (unknown) if not included anyway? I've made
SeqNumList optional for now.
Representation” section that says “if there is no SeqNum
associated with an address, add a SeqNum Address TLV with the
value 0” or something.
Otherwise, if all TLVs attached to the addresses are optional, we
have *the same problem* that we have with our orphaned
TargNodeAddresses– In case of any extension, we will have no way
of determining what these Addresses are all about.
* If we didn't include a MetricType, the receiver will assumeI don't think we can do any better with the existing protocol.
it relates to the default metric. Is this acceptable? We
could end up deleting the wrong route? Maybe we can't do
any better if we can't work out what MetricType we should
have associated with the packet?
QoS routing is NP hard, by the way.
That operation is explained in the text... since route table
* If we receive this RERR and there's no prefix length, we'll
assume prefix length is address length, i.e. one host is
unreachable. If our route is to the subnet that address is
on, what should we do?
entries are longest-match,
you can create an invalid route to the single host and you will
be O.K. to still reach the
other hosts on the subnet prefix.
* If we send the RERR to the next hop on our route to
PktSource, how can we be sure this is the route PktSource
used to forward the packet? (See also the email on
precursors - the following scenario is duplicated in that
email in the context of precursors)
Consider:
source -----> A ---------> B ----------> C ---------->
destination
| | ^
| | |
V V |
E --------> D -------------------------|
C's next hop to the source is B. When C receives a packet
from source which it cannot forward to destination, C sends
a RERR to B using the PktSource data element.
However, the packet might have come via D - the source
could be using the route via EDC. If the RERR goes to B, B
might regenerate it to A (or it might not be regenerated at
all), then A might regenerate it to source (or not
regenerate at all), and if it reaches the source, the
source will say "thats not my next hop, I don't care" and
ignore it. It will carry on sending packets via E and D,
and C will again say "I've got no route, send a RERR to
PktSource" (and the same thing happens again).
Either way, just because C's next hop to PktSource is B,
doesnt necessarily mean that PktSource used the route via B
and C to reach the destination. If the RERR goes back a
different way to the route PktSource is using, it will get
ignored, if not at an intermediate node, it will get
ignored by source.
I have not heard of this being a problem. However, if it needs
to be prevented,
we could say that the second RERR from missing route to a
destination should
be multicast.
Regards,
Charlie P.
Why dont we just multicast it anyway? By multicasting from the start, we avoid wasting messages (first the one C sends to B, then the one B might send to A, then the one A might send to PktSource), and we KNOW that PktSource will get it.And if our route isnt used by a router that receives our RERR, it wont regenerate it, simple. It only goes as far as it needs to.
Alternatively, Charlie's MAC address idea from the email about precursors will work.
Regards,
Vicky.
