[really lifting it from CC this time]
Hesham Soliman wrote:
Hi HEsham, I'm not sure how it's thought routers in the fixed
network load-balance traffic without informing end-hosts. IETF has
some nice qos reservation mechanisms that are triggered by
end-node after which routers in the middle look at packet markings
and load-balance accordingly. COPS, RSVP, Traffic Class, Diffserv
are keywords for search. It's the end-node who tags the packets
anyways.
=> This is not related to reality in deployed networks. End hosts
don't use RSVP and hosts hardly ever mark TOS fields.
Huh? RSVP-related RFCs date of last year, recent routers include COPS,
and end hosts routinely mark Traffic Class. What do you mean hosts
hardly ever mark ToS fields? You mean IPv4? I meant IPv6. Modern
wireless access networks have QoS features too.
Anyway, your response is not related to what I said earlier, routers
do split flows to different links all the time (of course one flow is
expected to take the same path in the network under normal
circumstances).
Routers split flows based on what specs? I think you agree we can't say
that because some non-specified flow splitting happens then we need to
specify a similar thing. It means actually we don't want to specify a
similar thing.
This is a fact
What RFC number?
and I don't see why an end host has to know which specific links its
traffic goes through on every hop. That makes no sense.
It depends. _If_ the MR decision to choose a different interface is
based on another interface link-down event then it's normal, it's about
keeping connectivity up for the LFN and the LFN can only be happy about
it. Core routers do the same when selecting paths.
If on the other hand, the decision to choose a different interface is
based on application needs, and MR may _think_ the LFN's application
prefers a certain interface - then it's totally different thing. And I
believe flow bindings fall into this category, because it has filters on
all possible fields in an application payload.
Have I got this right?
Alex
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
