Re: [PANRG] draft-rass-panrg-mpath-usecase

[<[e-mail]>]

Hi Yingzhen,

my take from the presentation was, that forwarding along different paths is a or the major design goal. If more than a single packet is forwarded that way by a single transport relation, adoption of a transport protocol may be an issue.

You write:

  *   Adding more source and destination address, if IGP is used to calculate routing, then you still end up on the same route because of SPF.
RG: the PANRG investigates the usage of different paths, not different routes, if I got that correctly. A layer 2 tunnel and a non-VPN layer 3 packet sent on different accesses may be forwarded along the same SPF routed path, if the CE routers are identical at both ends. As a general statement, I think it would help PANRG to specify what a path is. I doubt that any network provider will support a universal path infrastructure ping presenting everything from layer 0 - layer 3.
A fairly good method to determine whether different paths exist to me seems to be measuring RTTs of packets exchanged between end-points connected to one or more provider networks after address variation has been performed. The accesses shouldn't belong to the same access network section. On a single access network section, there may be little or no path variation.
  *   This will require change on hosts because you can't use one TCP or MPTCP session.

MPTCP is designed to use different paths by different addresses (and https://www.rfc-editor.org/rfc/rfc6182.txt mentions, that SCTP also supports multipath & multihoming). So MPTCP is based on the principle of different paths using different address-pairs already.

Of course, if additional address- or IPv6 flow label variation is introduced, more paths might be used. This could result in packet re-ordering at the destination. The transport and higher layers will have to cope with that. Varying source addresses will require transport adaptation anyway, if TCP is used. The ACKs need to get back to the sender.

Impacting forwarding path selection by different source and destination addresses is a fair approach within a single domain, I think. In the case of IPv6, the flow-label is an input used for ECMP, see https://www.rfc-editor.org/rfc/rfc6437.txt . Then the IP addresses may even be maintained and different paths may be addressed by varying the IPv6 flow-label.

Source address variation may fail, if uRPF is active, see https://tools.ietf.org/html/rfc3704 , and the source address isn't assigned to the access sending the packet. uPRF may be configured at consumer accesses.

Regards,

Ruediger


Von: Yingzhen Qu <[e-mail]>
Gesendet: Montag, 1. April 2019 23:45
An: Geib, Rüdiger <[e-mail]>; [e-mail]
Cc: Lin Han <[e-mail]>; [e-mail]; [e-mail]
Betreff: RE: draft-rass-panrg-mpath-usecase

Hi  Ruediger,

Thanks for your interests in our draft and comments at the mic during Stefan's presentation.

I didn't get a chance to answer your question during the presentation because of the shortness of time. If I understand right, you were suggesting to add different source and destination address to achieve multiple path, it is useful in some circumstances but I see some limitations. Let's take a single domain/AS as an example:

  *   Adding more source and destination address, if IGP is used to calculate routing, then you still end up on the same route because of SPF.
  *   This will require change on hosts because you can't use one TCP or MPTCP session.

Acrossing domains is more complicated, but the 2nd point still applies.

Thanks,
Yingzhen

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, March 28, 2019 7:23 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; Lin Han <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: draft-rass-panrg-mpath-usecase

Hi Stefan,

the idea to route packets containing encrypted information via different paths sound reasonable to me. This may be challenging for higher layers, but well, one may be able to design them to cope with packets received from different paths, I think.

I've recommended to investigate available options rather that path detection this morning. Some of these are:

  *   An end system can be multihomed
  *   There's multi-path transport, like MPTCP
  *   If the IP-addresses can be varied, the packets will likely follow different Equal Cost Multi-Path's (ECMP, search the Internet). Varying source address will do.

Multipath could mean:

  *   Same fiber, different router interfaces/headers (imagine the LTE path and fixed access sharing the same fiber at some part of a layer 0 path) .
  *   Different parallel ports of a router, but same router to router hop
  *   Different router hops (combined with different ports).

What likely is difficult is to vary the AS path. That might work, if you are multihomed with different networks. For a single domain, you may have to use a proxy or a tunnel to reach a different section of that domain (but I assume that there are multiple peerings to reach the destination AS - that might not be the case).

I'm not an onion routing expert. That may help too.

You could try different paths with the methods described above and measure delays to figure out different router paths (different ports between the same routers a hard to detect). No matter what you do, and even with path aware networking, you'll not be able to figure out or avoid using the same fiber by different networks.

Please note, I'm not on the panrg list and readers there may receive this message delayed. While I like your idea, my time doesn't suffice for an ongoing support.

Regards,

Ruediger