[IP-SFS] Re: Changes to IP over Semaphore Signals for April 1

[Jogi Hofmüller]

Hello Bob!

I am thrilled about the changes you made to the document!

* Bob Braden <braden at ISI.EDU> [2007-03-28 20:52]:

> Hi. I am trying to understand your spec (it SHOULD make technical 
> sense!).  I don't understand
> how the receiver knows the data length in one IP-SFS frame!?  Frame Hi and 
> Frame Lo are
> frame numbers, not frame length, right?

Right. The receiving side does NOT know the length of one IP-SFS frame.
That was no concern to us ... to be honest.

> As I understand it, the MTU for IP-SFS is (510/2+ 4) * 255 = 66045 octets, 
> right? 

That is correct.

> The max size of one
> frame is 510/2 octets of data plus 4 octets of header and trailer, while 
> the maximum number
> of frames is 255.

That is the idea.

> Each datagram is sent as one session, right?

Right.

> Another question: FST and FEN stand OUTSIDE of the frame shown in Fig 2, 
> right?

Right.

> How can SUN be one or more?  I don't understand how you keep SFS (flag) 
> synchronization
> after an error.

Actually, keeping sync on SUN is the job of an interface. That's how we
did it when trying it out. 5 SUNs need 5 canceled flags on the receiving
side. I had a sentence in one version that was referencing the backspace
key to explain how SUN should work.

> I also don't understand the limitations in section 3.6.

We tried to keep IP-SFS frames short since a successfully transmitted
frame could be checked and. Making frames longer could lead to the
transmission of many more signals until an error could be detected (one
could of course use correction techniques, but that was too much for
us). Therefore we limited the payload to a maximum of 510 SFS.
Transmitting a frame this size typically takes about 10 to 15 minutes
(if you are not a sailor). Anything longer proved inconvenient in case
of error and retransmission. Anything shorter would bring too much
overhead.

The maximal frames per session is because using 2 SFS one is limited to
an 8-bit number to be transmitted during the establishing a connection.

> Hi.  Since time is of the essence, I chose one reasonable set of answers to 
> my questions
> and edited your document accordingly -- to be more explicit on the issues 
> that troubled me.

You did a lot more than that and I am very gratefull!

> Attached is our current working copy.  This is not final... there are
> no doubt new errors I introduced, and the ToC is out of date, and
> there are probably many editorial problems.

> But I wanted to know whether you think I am on the wrong track with the 
> contents.

From my perspective you are on the right track. I browsed the attachment
you sent and found some very valuable additions :)

If it is OK with you I will check again 2morrow morning and also give my
co-authors a chance to review what you wrote. It's close to midnight
here and I doubt that anyone else is going to read what you wrote before
2morrow morning (CEST). The 9 hours time difference prove to be quite
disturbing here ;)

Kind regards,
j.hofmueller
-- 
Zahlreiche Pilze wachsen zwischen den Zehen von Luis Zechmeister. Ihre Farbe wechselt mit der Stimmung von Bernhard Neugebauer, der dies aber nicht bestätigen will. <<< http://plagi.at/geruecht/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mur.at/pipermail/ip-sfs/attachments/20070328/ddb5523f/attachment-0002.pgp