Subject: Re: architecture draft

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 May 2004 11:50:00 +0200

On 4-mei-04, at 16:27, Allison Mankin wrote:

> I'd like to provide a clarification about SCTP.

> SCTP was designed with its TCP-algorithm congestion control built-in,
> because its original emphasis was stream flows with TCP-like 
> characteristics.
> An application expecting a pure UDP datagram cannot avoid this 
> congestion
> control, so SCTP does not emulate UDP service in that it can neither
> drop all congestion control nor allow alternative congestion control.

Ok, that's obviously a problem. However, considering that everything 
that's on the table is going to require major changes to *something*, I 
don't think it's a show stopper.

> This has been discussed many times because of the question of whether 
> SCTP
> could be a transport for video and audio; it turns out TCP-like 
> congestion
> control is a poor service for realtime media, while TFRC (RFC 3448) is 
> an
> example of an algorithm tailored for their use, over RTP and UDP.

The main thing is that SCTP allows several streams within a session 
(maybe I got the official lingo wrong here, but you know what I mean), 
where each stream can be either long-lived in itself or not, and there 
is no delivery order constraint between streams so in that regard there 
is at least potential for using SCTP for real-time communication.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 05 May 2004 22:31:01 +1000

At 11:42 PM 4/05/2004, Iljitsch van Beijnum wrote:
>Hi,
>
>Some comments on the architecture draft.
>
>   "This implies that if a local multi-homed-aware host
>    establishes an application session with the remote host using "Path
>    a", and this path fails, the application session should be mapped
>    across to "Path b" without requiring any application-visible
>    re-establishment of the session."
>
>This is only the first multihoming issue. The other is that it should be 
>possible to set up new sessions.

good point - I'll add words

>   "RFC 3582 [RFC3582] documents some requirements that a multi-homing
>    approach should attempt to address."
>
>I think we decided against using the R-word but rather call them "goals".

Unless someone objects to this word change I'll agree to this.

>   "Within the constraints of current routing
>    and forwarding technologies it is not clearly evident that this
>    approach can scale to encompass a population of multi-homed sites of
>    the order of 10**7 such sites."
>
>Why this specific number?

It was a number larger than any claim I've heard from a vendor to date,
and it was a power of 10. (I've heard numbers of the scale of 10**6, not
verified of course)

>   "While the destination address is that of R, what
>    source address should the local host use? There are two implications
>    for this choice. Firstly the remote host will, by default use this
>    source address as the destination address in its response, and hence
>    this choice of source address will direct the reverse path from R to
>    the local host."
>
>While I agree that doing this sounds reasonable, there is no requirement 
>that this should be the case.

well, in the figure 1 model the remote host is not multi-homed, but would 
need to
be multi-home "aware", and I believe the "by default"  comment is correct.

>   "Secondly, the ISPs A and B may be using reverse
>    unicast address filtering on source addresses of packets passed to
>    the ISP, as a means of prevention of source address spoofing."
>
>The idea is that ISPs filter. Whether they use uRPF or some other way to 
>accomplish the same result isn't all that interesting.

In this case the description of the practice and the use of a reference
to an approach to doing this I though was the most concise way of describing
the practice.

>   "As an alternative to insertion of a new protocol stack element into
>    the protocol architecture, an alternative approach is to modify an
>    existing protocol stack element to include the functionality
>    performed by the EIP element. This modification could be undertaken
>    within the transport protocol stack element, or within the
>    internetworking stack element."
>
>Is there really a difference between having a wedge between the transport 
>and network layers and implementing the functionality in the "upper part" 
>of the IP protocol?

I believe so. As I said at the Seoul meeting a "new" protocol stack element
implies a distinct synchronization across to its peer. I know that there 
was some
discussion in the WG on this, but I did not sense that this proposition was
not accepted by the workling group.

>   "As a part of the EIP function is to transform the ULP PDU to include
>    locator information there is an associated requirement to ensure that
>    the EIP peering state remains synchronized to the exchange of ULP
>    PDUs, so that the remote EIP can correctly recognize the locator to
>    endpoint mapping for each active session."
>
>Depending on the meaning of the word "synchronize", I don't agree here. 
>This is very different from, say, TCP, where a three way handshake is 
>essential to synchronize the state at both ends. There is no reason such 
>tight synchronization is needed to provide multihoming functionality. If 
>such tight state synchronization is mandated, this leads to delays in the 
>actual communication because this can only start after the synchronization 
>is done. I don't think this is necessary.

I think we are talking at cross purposes.  The words are intended to say that
you should signal a new locator to the other end if you want the other end
to recognise the locator packet as part of an active session. That does not
mean you have to sync locators at transport startup, but it does say "signal
intentions before use".

>In this list:
>
>    o  Transport Layer Triggers
>    o  Routing Triggers
>    o  Heartbeat Triggers
>
>I'm missing ICMP triggers.

so I'll add these triggers to the list - thanks.

>         "One confusing question about the direction of this work is why
>          SCTP is being discussed as a "solution" to site multihoming,
>          when a clear requirement for a site multihoming solutions is
>          the ability to support existing TCP-based and UDP-based
>          applications."
>
>A cool aspect of SCTP is that it can both function in a way very similar 
>to TCP and in a way very similar to UDP. It should be possible to create 
>an adaption layer so that applications that expect to use TCP or UDP are 
>redirected over SCTP.

perhaps you could suggest some alternative words here?

>Some stuff I missed in the draft:
>
>  * multiaddressing by its ver nature means changes at both ends, which
>    is far from helpful in gettting things off the ground

agreed - again are there some general words you can propose to help me here?

>  * the implications of keeping the current socket API or ditching it

I'll propose that this is out of scope to this draft, being tactical rather 
than architectural,
and such issues should be in Eliot's draft, but if you believe that this is 
useful in this
architectural-oriented document some further explanation as to why would be
helpful.

>  * the application of MIPv6 mechanisms or MIPv6 lessons for multi6

hmmm - this was discussed at the meeting in Seoul, but the impression I 
gained from the
conversation was that the lesson was a case of maybe the MIPv6 approach was not
directly applicable. But again if you have wrds to propose here I would 
appreciate
your assistance.

>Also, security should be considered from the start. We've already seen 
>that many things that seem like good ideas can't work securely at all, or 
>need so much additional security stuff that the advantages or the original 
>approach are largely lost.

I agree with you - and indeed think that its  just so critical that it 
needs its own document
in its own right to explore the space and do it justice. That's the pointer 
in the draft in the
Security Considerations section.

thanks for your careful review, and please consider the invitations to 
contribute
some further words to the document as noted- I'd appreciate your 
assistance, of course.

regards,

    Geoff